idnits 2.17.1 draft-ietf-lsr-ip-flexalgo-05.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 13, 2022) is 714 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 784, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'RFC7684' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 845, 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 14, 2022 R. Shetty 6 R. Bonica 7 Juniper Networks 8 P. Psenak 9 Cisco Systems 10 May 13, 2022 12 IGP Flexible Algorithms (Flex-Algorithm) In IP Networks 13 draft-ietf-lsr-ip-flexalgo-05 15 Abstract 17 An IGP Flexible Algorithm (Flex-Algorithm) allows IGP 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 14, 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 ISIS 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 ISIS IPv4 Algorithm Prefix Reachability TLV . . . . . 6 68 6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV . . . . . 8 69 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV . . . 8 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 . . . . . . . . . . . . 12 73 8. IP Flex-Algorthm Forwarding . . . . . . . . . . . . . . . . . 13 74 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 75 10. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 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-Algorityhm 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 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 shortest latency path. Each UPF is assigned a unique IP address. As 115 a 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 be 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 Section 10.2 of 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 if participation in IP Flex-Algorithm MUST NOT impact 155 the router participation signalled for other data-planes. 157 Following sections describe how the IP Flex-Algorithm participation 158 is advertised in IGP protocols. 160 5.1. The ISIS IP Algorithm Sub-TLV 162 The ISIS [ISO10589] IP Algorithm Sub-TLV is a sub-TLV of the ISIS 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: ISIS 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 ISIS IP Algorithm 197 Sub-TLV is topology independent. When a router advertises 198 participation in ISIS IP Algorithm Sub-TLV, the participation applies 199 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 Opaque 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 Opaque LSA. If the IP Algorithm TLV appears in multiple 230 Router Information Opaque LSAs that have different flooding scopes, 231 the IP Algorithm TLV in the Router Information Opaque LSA with the 232 area-scoped flooding scope MUST be used. If the IP Algorithm TLV 233 appears in multiple Router Information Opaque LSAs that have the same 234 flooding scope, the IP Algorithm TLV in the Router Information (RI) 235 Opaque LSA with the numerically smallest Instance ID MUST be used and 236 subsequent instances of the IP Algorithm TLV MUST be ignored. 238 The RI LSA can be advertised at any of the defined opaque flooding 239 scopes (link, area, or Autonomous System (AS)). For the purpose of 240 IP Algorithm TLV advertisement, area-scoped flooding is REQUIRED. 242 The IP Flex-Algorithm participation advertised in OSPF IP Algorithm 243 TLV is topology independent. When a router advertises participation 244 in OSPF IP Algorithm TLV, the participation applies to all topologies 245 in which the advertising node participates. 247 6. Advertising IP Flex-Algorthm Reachability 249 To be able to associate the prefix with the Flex-Algorithm, the 250 existing prefix reachability advertisements can not be used, because 251 they advertise the prefix reachability in default algorithm 0. 252 Instead, a new IP Flex-Algorithm reachability advertisements are 253 defined in ISIS and OSPF. 255 The M-flag in FAD is not applicable to IP Algorithm Prefixes. Any IP 256 Algorithm Prefix advertisement includes the Algorithm and Metric 257 fields. When IP Algorithm Prefix is advertised between areas or 258 domains, the metric field in the IP Algorithm Prefix advertisement 259 MUST be used irrespective of the M-flag in the FAD advertisement. 261 6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV 263 A new top level TLV is defined for advertising IPv4 Flex-Algorithm 264 Prefix Reachability in ISIS - IPv4 Algorithm Prefix Reachability TLV. 266 This new TLV shares the sub-TLV space defined for TLVs Advertising 267 Prefix Reachability. 269 The ISIS IPv4 Algorithm Prefix Reachability TLV has the following 270 format: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Length |R|R|R|R| MTID | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 3: ISIS IPv4 Algorithm Prefix Reachability TLV 280 o Type: IPv4 Algorithm Prefix Reachability TLV (Value 126). 282 o Length: variable. 284 o R bits (4 bits): reserved for future use. They MUST be set to 285 zero on transmission and MUST be ignored on receipt. 287 o MTID (12 bits): Multitopology Identifier as defined in [RFC5120]. 288 Note that the value 0 is legal. 290 Followed by one or more prefix entries of the form: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Metric | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Flags | Algorithm | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Pfx Length | Prefix (variable)... 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Sub-tlv-len | Sub-TLVs (variable) . . . | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 4: ISIS IPv4 Algorithm Prefix Reachability TLV 306 o Metric (4 octets): Metric information. 308 o Flags (1 octet): 310 0 1 2 3 4 5 6 7 311 +-+-+-+-+-+-+-+-+ 312 |D| Reserved | 313 +-+-+-+-+-+-+-+-+ 315 D-flag: When the Prefix is leaked from level-2 to level-1, the 316 D bit MUST be set. Otherwise, this bit MUST be clear. 317 Prefixes with the D bit set MUST NOT be leaked from level-1 to 318 level-2. This is to prevent looping. 320 o Algorithm (1 octet): Associated Algorithm from 128 to 255. 322 o Prefix Len (1 octet): Prefix length measured in bits. 324 o Prefix (variable length): Prefix mapped to Flex-Algorithm. 326 o Optional Sub-TLV-length (1 octet): Number of octets used by sub- 327 TLVs 329 o Optional sub-TLVs (variable length). 331 A router receiving multiple IPv4 Algorithm Prefix Reachability 332 advertisements for the same prefix, from the same originator, each 333 with a different Algorithm, MUST select the first advertisement in 334 the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm 335 Prefix Reachability advertisements for the same prefix for any other 336 Algorithm. 338 A router receiving multiple IPv4 Algorithm Prefix Reachability 339 advertisements for the same prefix, from different originators, each 340 with a different Algorithm, MUST ignore all of them and MUST NOT 341 install any forwarding entries based on these advertisements. 343 In cases where a prefix advertisement is received in both a IPv4 344 Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability 345 TLV, the IPv4 Prefix Reachability advertisement MUST be preferred 346 when installing entries in the forwarding plane. 348 6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV 350 The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the 351 ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a 352 unique type. The type is 127. 354 A router receiving multiple IPv6 Algorithm Prefix Reachability 355 advertisements for the same prefix, from the same originator, each 356 with a different Algorithm, MUST select the first advertisement in 357 the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm 358 Prefix Reachability advertisements for the same prefix for any other 359 Algorithm. 361 A router receiving multiple IPv6 Algorithm Prefix Reachability 362 advertisements for the same prefix, from different originators, each 363 with a different Algorithm, MUST ignore all of them and MUST NOT 364 install any forwarding entries based on these advertisements. 366 In cases where a prefix advertisement is received in both an IPv6 367 Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability 368 TLV, the IPv6 Prefix Reachability advertisement MUST be preferred 369 when installing entries in the forwarding plane. 371 In cases where a prefix advertisement is received in both ISIS SRv6 372 Locator TLV and in ISIS IPv6 Algorithm Prefix Reachability TLV, the 373 receiver MUST ignore both of them and MUST NOT install any forwarding 374 entries based on these advertisements. 376 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV 378 A new Sub-TLV of OSPFv2 Extended Prefix TLV is defined for 379 advertising IP Algorithm Prefix Reachability in OSPFv2 - OSPFv2 IP 380 Algorithm Prefix Reachability Sub-TLV. 382 The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the following 383 format: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type | Length | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | MT-ID | Algorithm | Reserved | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Metric | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 5: OSPFv2 IP Algorithm Prefix Reachability Sub-TLV 397 o Type (2 octets) : The value is TBD. 399 o Length (1 octet): 8 401 o MT-ID (1 octet): Multi-Topology ID as defined in [RFC4915] 403 o Algorithm (1 octet): Associated Algorithm from 128 to 255. 404 Algorithm values are defined in the IGP Algorithm Type registry. 405 If the value of Algorithm is 0 the TLV MUST be ignored. 407 o Reserved: (2 octets). SHOULD be set to 0 on transmission and MUST 408 be ignored on reception. 410 o Metric (3 octets): The algorithm specific metric value. 412 A OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix 413 Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV, MUST 414 select the first advertisement of this Sub-TLV and MUST ignore all 415 remaining occurences of this Sub-TLV in the OSPFv2 Extended Prefix 416 TLV. 418 A OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix 419 Reachability TLVs for the same prefix, from different originators, 420 each with a different Algorithm, MUST ignore all of them and MUST NOT 421 install any forwarding entries based on these advertisements. 423 In cases where a prefix advertisement is received in any of the LSAs 424 advertising the prefix reachability for algorithm 0 and in an OSPFv2 425 IP Algorithm Prefix Reachability TLV, only the prefix reachability 426 advertisement for algorithm 0 MUST be used and all occurences of the 427 OSPFv2 IP Algorithm Prefix Reachability TLV MUST be ignored. 429 6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV 431 The OSPFv3 [RFC5340] IP Algorithm Prefix Reachability Sub-TLV is 432 defined for advertisement of the IP Algorithm Prefix Reachability in 433 OSPFv3. 435 The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of 436 the following OSPFv3 TLVs defined in [RFC8362]: 438 o Intra-Area-Prefix TLV 440 o Inter-Area-Prefix TLV 442 o External-Prefix TLV 444 The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is 445 shown below: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Algorithm | Reserved | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Metric | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 6: OSPFv3 Algorithm Prefix Sub-TLV 459 Where: 461 Type (3 octets): The value is TBD. 463 Length (2 octets): 4. 465 Algorithm (1 octet): Associated Algorithm from 128 to 255. 466 Algorithm values are defined in the IGP Algorithm Type registry. 467 If the value of Algorithm is 0 the TLV MUST be ignored. 469 Reserved: (3 octets). SHOULD be set to 0 on transmission and MUST 470 be ignored on reception. 472 Metric (4 octets): The algorithm specific metric value. 474 When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is present, 475 the metric value in its parent TLV MUST be set to LSInfinity 476 [RFC2328]. If the metric value in the parent TLV is not set to 477 LSInfinity, the OSPFv3 IP Algorithm Prefix Sub-TLV MUST be ignored by 478 the receiver. 480 A OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix 481 Reachability Sub-TLVs in the same parent TLV, MUST select the first 482 advertisement of this Sub-TLV and MUST ignore all remaining 483 occurences of this Sub-TLV in the parent TLV. 485 A OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix 486 Reachability TLVs for the same prefix, from different originators, 487 each with a different Algorithm, MUST ignore all of them and MUST NOT 488 install any forwarding entries based on these advertisements. 490 In cases where a prefix advertisement is received in any of the LSAs 491 advertising the prefix reachability for algorithm 0 and in an OSPFv3 492 OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, only the prefix 493 reachability advertisement for algorithm 0 MUST be used and all 494 occurences of the OSPFv3 IP Algorithm Prefix Reachability TLV MUST be 495 ignored. 497 In cases where a prefix advertisement is received in both OSPFv3 SRv6 498 Locator TLV and in OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, 499 the receiver MUST ignore both of them and MUST NOT install any 500 forwarding entries based on these advertisements. 502 6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV 504 Section 10.2 of the [I-D.ietf-lsr-flex-algo] defines the OSPF 505 Flexible Algorithm ASBR Metric Sub-TLV (FAAM) that is used by OSPFv2 506 and OSPFv3 to advertise Flex-Algorithm specific metric associated 507 with a given ASBR reachability advertisement by an ABR. 509 As described in section 11 of [I-D.ietf-lsr-flex-algo] each data- 510 plane signals the participation independently. IP Flex-Algorithm 511 participation is signalled independently of the Segment Routing (SR) 512 Flex-Algorithm participation. As a result, the calculated topologies 513 for SR and IP Flex-Algorithm could be different. Such difference 514 prevents the usage of FAAM for the purpose of the IP Flex-Algorithm. 516 The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is 517 defined for the advertisement of the IP Flex-Algorithm specific 518 metric associated with an ASBR by the ABR. 520 The IPFAAM Sub-TLV is a Sub-TLV of the: 522 - OSPFv2 Extended Inter-Area ASBR TLV as defined in 523 [I-D.ietf-lsr-flex-algo] 524 - OSPFv3 Inter-Area-Router TLV defined in [RFC8362] 526 OSPF IPFAAM Sub-TLV has the following format: 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Type | Length | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Algorithm | Reserved | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Metric | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 where: 540 Figure 7: OSPF IP Flexible Algorithm ASBR Metric Sub-TLV 542 Type (2 octets): TBD for OSPFv2, TBD for OSPFv3. 544 Length (2 octets): 8. 546 Algorithm (1 octet): Associated Algorithm from 128 to 255. 547 Algorithm values are defined in the IGP Algorithm Type registry. 548 If the value of Algorithm is 0 the TLV MUST be ignored. 550 Reserved: (3 octets). SHOULD be set to 0 on transmission and MUST 551 be ignored on reception. 553 Metric (4 octets): The algorithm specific metric value. 555 The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM 556 Sub-TLV defined in [I-D.ietf-lsr-flex-algo], but it is used to 557 advertise IP Flex-Algorithm metric. 559 An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of the ASBR 560 reachability advertisement between areas for every IP Flex-Algorithm 561 in which it participates and the ASBR is reachable in. 563 FAAM Sub-TLV as defined in [I-D.ietf-lsr-flex-algo] MUST NOT be used 564 during IP Flex-Algorithm path calculation, IPFAAM Sub-TLV MUST be 565 used instead. 567 7. Calculating of IP Flex-Algorthm Paths 569 IP Flex-Algorthm is considered as yet another data-plane of the Flex- 570 Algorithm as described in Section 10 and Section 12 of the 571 [I-D.ietf-lsr-flex-algo]. 573 Participation for the IP Flex-Algorithm is signalled as described in 574 Section 5 and is specific to the IP Flex-Algorithm data-plane. 576 Calculation of IP Flex-Algorithm paths follows the Section 12 of 577 [I-D.ietf-lsr-flex-algo]. This computation uses the IP Flex- 578 Algorithm data-plane participation and is independent of the Flex- 579 Algorithm calculation done for any other Flex-Algorithm data-plane 580 (e.g. SR, SRv6). 582 IP Flex-Algorithm data-plane only considers participating nodes 583 during the Flex-Algorithm calculation. When computing paths for a 584 given Flex-Algorithm, all nodes that do not advertise participation 585 for IP Flex-Algorithm, as described in Section 5, MUST be pruned from 586 the topology. 588 8. IP Flex-Algorthm Forwarding 590 IP Algorithm Prefix Reachability advertisement as described in 591 Section 5 includes the MTID value that associates the prefix with a 592 specific topology. Algorithm Prefix Reachability advertisement also 593 includes an Algorithm value that explicitly associates the prefix 594 with a specific Flex-Algorithm. The paths to the prefix MUST be 595 calculated using the specified Flex-Algorithm in the associated 596 topology. 598 Forwarding entries for the IP Flex-Algorithm prefixes advertised in 599 IGPs MUST be installed in the forwarding plane of the receiving IP 600 Flex-Algorithm prefix capable routers when they participate in the 601 associated topology and algorithm. Forwarding entries for IP Flex- 602 Algorithm prefixes associated with Flex-Algorithms in which the node 603 is not participating MUST NOT be installed in the forwarding plane. 605 When the IP Flex-Algorithm prefix is associated with a Flex- 606 Algorithm, LFA paths to the prefix MUST be calculated using such 607 Flex-Algorithm in the associated topology, to guarantee that they 608 follow the same constraints as the calculation of the primary paths. 610 9. Deployment Considerations 612 IGP Flex-Algorithm can be used by many data-planes. Original 613 specification was done for SR and SRv6, this specification adds IP as 614 another data-plane that can use IGP Flex-Algorithm. Other data- 615 planes may be defined in the future. This section provides some 616 details about the coexistence of the various data-planes of the IGP 617 Flex-Algorithm. 619 Flex-Algorithm definition (FAD), as described in 620 [I-D.ietf-lsr-flex-algo], is data-plane independent and is used by 621 all Flex-Algorithm data-planes. 623 Participation in the Flex-Algorithm, as described in 624 [I-D.ietf-lsr-flex-algo], is data-plane specific. 626 Calculation of the flex-algo paths is data-plane specific and uses 627 data-plane specific participation advertisements. 629 Data-plane specific participation and calculation guarantee that the 630 forwarding of the traffic over the Flex-Algorithm data-plane specific 631 paths is consistent between all nodes over which the traffic is being 632 forwarded. 634 Multiple data-planes can use the same Flex-Algorithm value at the 635 same time and and as such share the FAD for it. For example SR-MPLS 636 and IP can both use such common Flex-Algorithm. Traffic for SR-MPLS 637 will be forwarded based on Flex-algorithm specific SR SIDs. Traffic 638 for IP Flex-Algorithm will be forwarded based on Flex-Algorithm 639 specific prefix reachability announcements. Note, that for a 640 particular Flex-Algorithm, for a particular IP prefix, there will be 641 path(s) calculated and installed for a single data-plane only. 643 10. Protection 645 In many networks where IGP Flexible Algorithms are deployed, IGP 646 restoration will be fast and additional protection mechanisms will 647 not be required. IGP restoration may be enhanced by Equal Cost 648 Multipath (ECMP). 650 In other networks, operators can deploy additional protection 651 mechanisms. The following are examples: 653 o Loop Free Alternates (LFA) [RFC5286] 655 o Remote Loop Free Alternates (R-LFA) [RFC7490] 657 LFA and R-LFA computations MUST be restricted to the flex-algo 658 topology and the computed backup nexthops should be programmed for 659 the IP flex-algo prefixes. 661 11. IANA Considerations 663 This specification updates the OSPF Router Information (RI) TLVs 664 Registry as follows: 666 +-------+------------------+---------------------------+ 667 | Value | TLV Name | Reference | 668 +-------+------------------+---------------------------+ 669 | TBD | IP Algorithm TLV | This Document Section 5.2 | 670 +-------+------------------+---------------------------+ 672 Table 1 674 This document also updates the "Sub-TLVs for TLV 242" registry as 675 follows: 677 +-------+----------------------+---------------------------+ 678 | Value | TLV Name | Reference | 679 +-------+----------------------+---------------------------+ 680 | 29 | IP Algorithm Sub-TLV | This Document Section 5.1 | 681 +-------+----------------------+---------------------------+ 683 Table 2 685 This document also updates the "ISIS TLV Codepoints Registry" 686 registry as follows: 688 +-------+------------------+-----+-----+-----+-------+--------------+ 689 | Value | TLV Name | IIH | LSP | SNP | Purge | Reference | 690 +-------+------------------+-----+-----+-----+-------+--------------+ 691 | 126 | IPv4 Algorithm | N | Y | N | N | This | 692 | | Prefix | | | | | document, | 693 | | Reachability TLV | | | | | Section 6.1 | 694 | 127 | IPv6 Algorithm | N | Y | N | N | This | 695 | | Prefix | | | | | document, | 696 | | Reachability TLV | | | | | Section 6.2 | 697 +-------+------------------+-----+-----+-----+-------+--------------+ 699 Table 3 701 Above new TLVs share the sub-TLV space defined in "IS-IS Sub-TLVs for 702 TLVs Advertising Prefix Reachability". This document updates the 703 description of that registry by including IPv4 Algorithm Prefix 704 Reachability TLV and IPv6 Algorithm Prefix Reachability TLV. It also 705 includes these TLVs in a table which lists the presence of Sub-TLVs 706 in a parent TLVs as follows: 708 Type Description 126 127 709 ---- ---------------------------------- --- --- 710 1 32-bit Administrative Tag Sub-TLV y y 711 2 64-bit Administrative Tag Sub-TLV y y 712 3 Prefix Segment Identifier n n 713 4 Prefix Attribute Flags y y 714 5 SRv6 End SID n n 715 6 Flex-Algorithm Prefix Metric n n 716 11 IPv4 Source Router ID y y 717 12 IPv6 Source Router ID y y 718 32 BIER Info n n 720 This document updates the "OSPFv2 Extended Prefix TLV Sub-TLVs" 721 registry as follows: 723 +-------+-----------------------------------+-----------------------+ 724 | Value | TLV Name | Reference | 725 +-------+-----------------------------------+-----------------------+ 726 | TBD | OSPFv2 IP Algorithm Prefix | This Document, | 727 | | Reachability TLV | Section 6.3 | 728 +-------+-----------------------------------+-----------------------+ 730 Table 4 732 This document updates the "OSPFv3 Extended-LSA Sub-TLVs" registry as 733 follows: 735 +-------+-------------------------------------+---------------------+ 736 | Value | TLV Name | Reference | 737 +-------+-------------------------------------+---------------------+ 738 | TBD | OSPFv3 IP Algorithm Prefix | This Document, | 739 | | Reachability Sub-TLV | Section 6.4 | 740 | TBD | OSPFv3 IP Flexible Algorithm ASBR | This Document, | 741 | | Metric Sub-TLV | Section 6.5 | 742 +-------+-------------------------------------+---------------------+ 744 Table 5 746 This document updates the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs" 747 registry as follows: 749 +-------+------------------------------------+----------------------+ 750 | Value | TLV Name | Reference | 751 +-------+------------------------------------+----------------------+ 752 | 2 | OSPF IP Flexible Algorithm ASBR | This Document, | 753 | | Metric Sub-TLV | Section 6.5 | 754 +-------+------------------------------------+----------------------+ 756 Table 6 758 12. Security Considerations 760 This document inherits security considerations from 761 [I-D.ietf-lsr-flex-algo]. 763 13. Acknowledgements 765 Thanks to Bruno Decraene for his contributions to this document. 766 Special thanks to Petr Bonbon Adamec of Cesnet for supporting 767 interoperability testing. 769 14. References 771 14.1. Normative References 773 [I-D.ietf-lsr-flex-algo] 774 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 775 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 776 algo-19 (work in progress), April 2022. 778 [ISO10589] 779 IANA, "Intermediate system to Intermediate system routing 780 information exchange protocol for use in conjunction with 781 the Protocol for providing the Connectionless-mode Network 782 Service (ISO 8473)", August 1987, . 784 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 785 DOI 10.17487/RFC0791, September 1981, 786 . 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, 790 DOI 10.17487/RFC2119, March 1997, 791 . 793 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 794 DOI 10.17487/RFC2328, April 1998, 795 . 797 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 798 (TE) Extensions to OSPF Version 2", RFC 3630, 799 DOI 10.17487/RFC3630, September 2003, 800 . 802 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 803 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 804 RFC 4915, DOI 10.17487/RFC4915, June 2007, 805 . 807 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 808 Topology (MT) Routing in Intermediate System to 809 Intermediate Systems (IS-ISs)", RFC 5120, 810 DOI 10.17487/RFC5120, February 2008, 811 . 813 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 814 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 815 2008, . 817 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 818 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 819 . 821 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 822 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 823 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 824 2015, . 826 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 827 S. Shaffer, "Extensions to OSPF for Advertising Optional 828 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 829 February 2016, . 831 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 832 for Advertising Router Information", RFC 7981, 833 DOI 10.17487/RFC7981, October 2016, 834 . 836 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 837 Writing an IANA Considerations Section in RFCs", BCP 26, 838 RFC 8126, DOI 10.17487/RFC8126, June 2017, 839 . 841 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 842 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 843 May 2017, . 845 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 846 (IPv6) Specification", STD 86, RFC 8200, 847 DOI 10.17487/RFC8200, July 2017, 848 . 850 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 851 F. Baker, "OSPFv3 Link State Advertisement (LSA) 852 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 853 2018, . 855 14.2. Informative References 857 [IANA-ALG] 858 IANA, "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY 859 TLV)", August 1987, . 862 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 863 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 864 DOI 10.17487/RFC5286, September 2008, 865 . 867 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 868 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 869 RFC 7490, DOI 10.17487/RFC7490, April 2015, 870 . 872 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 873 Decraene, B., Litkowski, S., and R. Shakir, "Segment 874 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 875 July 2018, . 877 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 878 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 879 (SRv6) Network Programming", RFC 8986, 880 DOI 10.17487/RFC8986, February 2021, 881 . 883 Authors' Addresses 885 William Britto 886 Juniper Networks 887 Elnath-Exora Business Park Survey 888 Bangalore, Karnataka 560103 889 India 891 Email: bwilliam@juniper.net 892 Shraddha Hegde 893 Juniper Networks 894 Elnath-Exora Business Park Survey 895 Bangalore, Karnataka 560103 896 India 898 Email: shraddha@juniper.net 900 Parag Kaneriya 901 Juniper Networks 902 Elnath-Exora Business Park Survey 903 Bangalore, Karnataka 560103 904 India 906 Email: pkaneria@juniper.net 908 Rejesh Shetty 909 Juniper Networks 910 Elnath-Exora Business Park Survey 911 Bangalore, Karnataka 560103 912 India 914 Email: mrajesh@juniper.net 916 Ron Bonica 917 Juniper Networks 918 2251 Corporate Park Drive 919 Herndon, Virginia 20171 920 USA 922 Email: rbonica@juniper.net 924 Peter Psenak 925 Cisco Systems 926 Apollo Business Center 927 Mlynske nivy 43, Bratislava 82109 928 Slovakia 930 Email: ppsenak@cisco.com