idnits 2.17.1 draft-ietf-lsr-ip-flexalgo-02.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 (April 28, 2021) is 1091 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: 'RFC2328' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 697, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 7 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: October 30, 2021 R. Shetty 6 R. Bonica 7 Juniper Networks 8 P. Psenak 9 Cisco Systems 10 April 28, 2021 12 IGP Flexible Algorithms (Flex-Algorithm) In IP Networks 13 draft-ietf-lsr-ip-flexalgo-02 15 Abstract 17 An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute 18 constraint-based paths. As currently defined, IGP Flex-Algorithm is 19 used with Segment Routing (SR) data planes - SR MPLS and SRv6. 20 Therefore, Flex-Algorithm cannot be deployed in the absence of SR. 22 This document extends IGP Flex-Algorithm, so that it can be used for 23 regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be 24 deployed in any IP network, even in the absence of SR. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 30, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Egress Node Procedures . . . . . . . . . . . . . . . . . . . 3 63 4. Advertising Flex-Algorithm Definitions (FAD) . . . . . . . . 3 64 5. Advertising IP Flex-Algorithm Participation . . . . . . . . . 3 65 5.1. The ISIS IP Algorithm Sub-TLV . . . . . . . . . . . . . . 4 66 5.2. The OSPF IP Algorithm TLV . . . . . . . . . . . . . . . . 5 67 6. Advertising IP Flex-Algorthm Reachability . . . . . . . . . . 6 68 6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV . . . . . 6 69 6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV . . . . . 8 70 6.3. The OSPFv2 Algorithm Prefix Reachability TLV . . . . . . 9 71 6.4. The OSPFv3 Flex-Algorithm IP Prefix Opaque LSA . . . . . 11 72 7. Calculating of IP Flex-Algorthm Paths . . . . . . . . . . . . 11 73 8. IP Flex-Algorthm Forwarding . . . . . . . . . . . . . . . . . 12 74 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 75 10. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 14.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 93 [I-D.ietf-spring-srv6-network-programming]. 95 Therefore, Flex-Algorithm cannot be deployed in the absence of SR and 96 SRv6. 98 This document extends Flex-Algorithm, allowing it to compute paths 99 to: 101 o An IPv4 [RFC0791] address. 103 o An IPv6 [RFC8200] address. 105 This allows Flex-Algorithm to be deployed in any IP network, even in 106 the absence of SR and SRv6. 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. Egress Node Procedures 118 Network operators configure multiple loopback interfaces on an egress 119 node. They associate one or more IP addresses with each loopback 120 interface and one Flex-Algorithm with each IP address. 122 If a packet is sent to a loopback address, and the loopback address 123 is not associated with a Flex-Algorithm, the packet follows the IGP 124 least-cost path to the egress node. If a packet is sent to a 125 loopback address, and the loopback address is associated with a Flex- 126 Algorithm, the packet follows the constraint-base path that the Flex- 127 Algorithm calculated. 129 4. Advertising Flex-Algorithm Definitions (FAD) 131 To guarantee loop free forwarding, all routers that participate in a 132 Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD). 134 Selected nodes within the IGP domain MUST advertise FADs as described 135 in Sections 5, 6 and 7 of [I-D.ietf-lsr-flex-algo]. 137 5. Advertising IP Flex-Algorithm Participation 139 A node may use various algorithms when calculating paths to nodes and 140 prefixes. Algorithm values are defined in the IGP Algorithm Type 141 Registry [IANA-ALG]. 143 A node MUST participate in a Flex-Algorithm to be: 145 o able to compute path for such Flex-Algorithm 147 o be part of the topology for such Flex-Algorithm 149 Flex-Algorithm participation MUST be advertised for each Flex- 150 Algorithm application independently, as specified in Section 10.2 of 151 [I-D.ietf-lsr-flex-algo]. Using Flex-Algorithm for regular IPv4 and 152 IPv6 prefixes represents a new Flex-Algorithm application (IP Flex- 153 Algorithm), and as such the Flex-Algorithm participation for the IP 154 Flex-Algorithm application MUST be signalled independently of any 155 other Flex-Algorithm applications (e.g. SR). 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 IP Algorithm Sub-TLV is a sub-TLV of the ISIS Router 163 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 1 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 SHOULD select the first 189 advertisement in the lowest-numbered LSP and subsequent instances of 190 the IP Algorithm Sub-TLV MUST be ignored. 192 The IP Algorithm Sub-TLV advertises the participation in Flex- 193 Algorithms, and MUST NOT impact the router participation in default 194 algorithm 0. The IP Algorithm Sub-TLV could be used to advertise 195 support for non-zero standard algorithms, but that is outside the 196 scope of this document. 198 The IP Flex-Algorithm participation advertised in ISIS IP Algorithm 199 Sub-TLV is topology independent. When a router advertises 200 participation in ISIS IP Algorithm Sub-TLV, the participation applies 201 to all topologies in which the advertising node participates. 203 5.2. The OSPF IP Algorithm TLV 205 The OSPF IP Algorithm TLV is a top-level TLV of the Router 206 Information Opaque LSA [RFC7770] and has the following format: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Algorithm 1 | Algorithm... | Algorithm n | | 214 +- -+ 215 | | 216 + + 218 Figure 2: OSPF IP Algorithm TLV 220 o Type: IP Algorithm TLV (Value TBD by IANA) 222 o Length: Variable 224 o Algorithm (1 octet): value from 1 to 255. 226 The IP Algorithm TLV is optional. It SHOULD only be advertised once 227 in the Router Information Opaque LSA. 229 When multiple IP Algorithm TLVs are received from a given router, the 230 receiver MUST use the first occurrence of the TLV in the Router 231 Information Opaque LSA. If the IP Algorithm TLV appears in multiple 232 Router Information Opaque LSAs that have different flooding scopes, 233 the IP Algorithm TLV in the Router Information Opaque LSA with the 234 area-scoped flooding scope MUST be used. If the IP Algorithm TLV 235 appears in multiple Router Information Opaque LSAs that have the same 236 flooding scope, the IP Algorithm TLV in the Router Information (RI) 237 Opaque LSA with the numerically smallest Instance ID MUST be used and 238 subsequent instances of the IP Algorithm TLV MUST be ignored. 240 The RI LSA can be advertised at any of the defined opaque flooding 241 scopes (link, area, or Autonomous System (AS)). For the purpose of 242 IP Algorithm TLV advertisement, area-scoped flooding is REQUIRED. 244 The IP Algorithm TLV advertises the participation in Flex-Algorithms, 245 and MUST NOT impact the router participation in default algorithm 0. 246 The IP Algorithm TLV could be used to advertise support for non-zero 247 standard algorithms, but that is outside the scope of this document. 249 The IP Flex-Algorithm participation advertised in OSPF IP Algorithm 250 TLV is topology independent. When a router advertises participation 251 in OSPF IP Algorithm TLV, the participation applies to all topologies 252 in which the advertising node participates. 254 6. Advertising IP Flex-Algorthm Reachability 256 To be able to associate the prefix with the Flex-Algorithm, the 257 existing prefix reachability advertisements can not be used, because 258 they advertise the prefix reachability in default algorithm 0. 259 Instead, a new IP Flex-Algorithm reachability advertisements are 260 defined in ISIS and OSPF. 262 Two new top-level TLVs are defined in ISIS [ISO10589] to advertise 263 prefix reachability associated with a Flex-Algorithm. 265 o The IPv4 Algorithm Prefix Reachability TLV 267 o The IPv6 Algorithm Prefix Reachability TLV 269 New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684] is 270 defined to advertise prefix reachability associated with a Flex- 271 Algorithm in OSPFv2. 273 6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV 275 A new top level TLV is defined for advertising IPv4 Flex-Algorithm 276 Prefix Reachability in ISIS - IPv4 Algorithm Prefix Reachability TLV. 278 This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236 279 and 237. 281 The ISIS IPv4 Algorithm Prefix Reachability TLV has the following 282 format: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Length |R|R|R|R| MTID | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 ISIS IPv4 Algorithm Prefix Reachability TLV 292 o Type: IPv4 Algorithm Prefix Reachability TLV (Value 126). 294 o Length: variable. 296 o R bits (4 bits): reserved for future use. They MUST be set to 297 zero on transmission and MUST be ignored on receipt. 299 o MTID (12 bits): Multitopology Identifier as defined in [RFC5120]. 300 Note that the value 0 is legal. 302 Followed by one or more prefix entries of the form: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Metric | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Flags | Algorithm | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Pfx Length | Prefix (variable)... 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Sub-tlv-len | Sub-TLVs (variable) . . . | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ISIS IPv4 Algorithm Prefix Reachability TLV 318 o Metric (4 octets): Metric information. 320 o Flags (1 octet): 322 0 1 2 3 4 5 6 7 323 +-+-+-+-+-+-+-+-+ 324 |D|S| | | 325 +-+-+-+-+-+-+-+-+ 327 D-flag: When the Prefix is leaked from level-2 to level-1, the 328 D bit MUST be set. Otherwise, this bit MUST be clear. 329 Prefixes with the D bit set MUST NOT be leaked from level-1 to 330 level-2. This is to prevent looping. 332 S-flag: Set when Sub-TLVs are present for the prefix entry. 334 o Algorithm (1 octet): Associated Algorithm from 1 to 255. 336 o Prefix Len (1 octet): Prefix length measured in bits. 338 o Prefix (variable length): Prefix mapped to Flex-Algorithm. 340 o Optional Sub-TLV-length (1 octet): Number of octets used by sub- 341 TLVs 343 o Optional sub-TLVs (variable length). 345 A router receiving multiple IPv4 Algorithm Prefix Reachability 346 advertisements for the same prefix, from the same originator, each 347 with a different Algorithm, MUST select the first advertisement in 348 the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm 349 Prefix Reachability advertisements for the same prefix for any other 350 Algorithm. 352 A router receiving multiple IPv4 Algorithm Prefix Reachability 353 advertisements for the same prefix, from different originators, each 354 with a different Algorithm, MUST ignore all of them and MUST NOT 355 install any forwarding entries based on these advertisements. 357 In cases where a prefix advertisement is received in both a IPv4 358 Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability 359 TLV, the IPv4 Prefix Reachability advertisement MUST be preferred 360 when installing entries in the forwarding plane. 362 6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV 364 The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the 365 ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a 366 unique type. The type is 127. 368 A router receiving multiple IPv6 Algorithm Prefix Reachability 369 advertisements for the same prefix, from the same originator, each 370 with a different Algorithm, MUST select the first advertisement in 371 the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm 372 Prefix Reachability advertisements for the same prefix for any other 373 Algorithm. 375 A router receiving multiple IPv6 Algorithm Prefix Reachability 376 advertisements for the same prefix, from different originators, each 377 with a different Algorithm, MUST ignore all of them and MUST NOT 378 install any forwarding entries based on these advertisements. 380 In cases where a prefix advertisement is received in both a IPv6 381 Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability 382 TLV, the IPv6 Prefix Reachability advertisement MUST be preferred 383 when installing entries in the forwarding plane. 385 6.3. The OSPFv2 Algorithm Prefix Reachability TLV 387 A new top level TLV of OSPFv2 Extended Prefix Opaque LSA is defined 388 for advertising IPv4 Algorithm Prefix Reachability in OSPFv2 - OSPF 389 Algorithm Prefix Reachability TLV 391 Multiple Algorithm Prefix Reachability TLV MAY be advertised in each 392 OSPFv2 Extended Prefix Opaque LSA. However, since the opaque LSA 393 type defines the flooding scope, the LSA flooding scope MUST satisfy 394 the application specific requirements for all the prefixes included 395 in a single OSPFv2 Extended Prefix Opaque LSA. The Algorithm Prefix 396 Reachability TLV has the following format: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Length | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Route Type | Prefix Length | AF | Flags | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | MT-ID | Algorithm | Reserved | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Address Prefix (variable) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Metric | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Sub-TLVs (variable) | 412 +- -+ 413 | | 415 OSPFv2 Algorithm Prefix Reachability TLV 417 Type: Algorithm Prefix Reachability TLV (Value TBD by IANA). 419 Length: Variable dependent on sub-TLVs. 421 Route Type (1 octet): type of the OSPF route. Supported types 422 are: 424 1 - Intra-Area 425 2 - Inter-Area 427 3 - AS External with Type-1 Metric 429 4 - AS External with Type-2 Metric 431 5 - NSSA External with Type-1 Metric 433 6 - NSSA External with Type-2 Metric 435 Prefix Length (1 octet): Length of prefix in bits. 437 AF (1 octet): Address family for the prefix. Currently, the only 438 supported value is 0 for IPv4 unicast. The inclusion of address 439 family in this TLV allows for future extension. 441 Flags (1 octet): Flags applicable to the prefix. Supported Flags 442 include: 444 0x80 - A-Flag (Attach flag): An Area Border Router (ABR) 445 generating an Extended Prefix TLV for inter-area prefix that is 446 locally connected or attached in other connected area SHOULD 447 set this flag. 449 0x40 - N-Flag (Node Flag): Set when the prefix identifies the 450 advertising router i.e., the prefix is a host prefix 451 advertising a globally reachable address typically associated 452 with a loopback address. The advertising router MAY choose to 453 not set this flag even when the above conditions are met. If 454 the flag is set and the prefix length is not a host prefix then 455 the flag MUST be ignored. The flag is preserved when the 456 OSPFv2 Extended Prefix Opaque LSA is propagated between areas. 458 MT-ID (1 octet): Multi-Topology ID as defined in [RFC8402] 460 Algorithm: (1 octet). Associated Algorithm from 1 to 255. 462 Adress Prefix: For the address family IPv4 unicast, the prefix 463 itself encoded as a 32-bit value. The default route is 464 represented by a prefix of length 0. Prefix encoding for other 465 address families is beyond the scope of this specification. 467 Metric (4 octets): Metric information. 469 If this TLV is advertised multiple times for the same prefix in the 470 same OSPFv2 Extended Prefix Opaque LSA, only the first instance of 471 the TLV is used by receiving OSPFv2 Routers. This situation SHOULD 472 be logged as an error. 474 If this TLV is advertised multiple times for the same prefix in 475 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 476 OSPF router, the OSPF advertising router is re-originating Extended 477 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 478 Algorithm Prefix Reachability TLVs in Extended Prefix Opaque LSAs. 479 In this case, the Algorithm Prefix Reachability TLV in the Extended 480 Prefix Opaque LSA with the smallest Opaque ID is used by receiving 481 OSPFv2 Routers. This situation may be logged as a warning. 483 It is RECOMMENDED that OSPF routers advertising Algorithm Prefix 484 Reachability TLVs in different Extended Prefix Opaque LSAs re- 485 originate these LSAs in ascending order of Opaque ID to minimize the 486 disruption. 488 A router receiving multiple Algorithm Prefix Reachability TLVs for 489 the same prefix, from different originators, each with a different 490 Algorithm, MUST ignore all of them and MUST NOT install any 491 forwarding entries based on these advertisements. 493 In cases where a prefix advertisement is received in any of the LSAs 494 advertising the prefix reachability for algorithm 0 (Router-LSA, 495 Summary-LSA, AS-external-LSA or NSSA AS-external LSA) and in an IPv4 496 Algorithm Prefix Reachability TLV, the prefix reachability 497 advertisement for algorithm 0 MUST be preferred when installing 498 entries in the forwarding plane, regardless of the Route Type 499 advertised in IPv4 Algorithm Prefix Reachability TLV. 501 6.4. The OSPFv3 Flex-Algorithm IP Prefix Opaque LSA 503 TBD. 505 7. Calculating of IP Flex-Algorthm Paths 507 IP Flex-Algorthm is considered as yet another application of the 508 Flex-Algorithm as described in Section 10 and Section 12 of the 509 [I-D.ietf-lsr-flex-algo]. 511 Participation for the IP Flex-Algorithm is signalled as described in 512 Section 5 and is specific to the IP Flex-Algorithm application. 514 Calculation of IP Flex-Algorithm paths follows the Section 12 of 515 [I-D.ietf-lsr-flex-algo]. This computation uses the IP Flex- 516 Algorithm participation and is independent of the Flex-Algorithm 517 calculation done for any other Flex-Algorithm applications (e.g. SR, 518 SRv6). 520 IP Flex-Algorithm application only considers participating nodes 521 during the Flex-Algorithm calculation. When computing paths for a 522 given Flex-Algorithm, all nodes that do not advertise participation 523 for IP Flex-Algorithm, as described in Section 5, MUST be pruned from 524 the topology. 526 8. IP Flex-Algorthm Forwarding 528 IP Algorithm Prefix Reachability advertisement as described in 529 Section 5 includes the MTID value that associates the prefix with a 530 specific topology. Algorithm Prefix Reachability advertisement also 531 includes an Algorithm value that explicitly associates the prefix 532 with a specific Flex-Algorithm. The paths to the prefix MUST be 533 calculated using the specified Flex-Algorithm in the associated 534 topology. 536 Forwarding entries for the IP Flex-Algorithm prefixes advertised in 537 IGPs MUST be installed in the forwarding plane of the receiving IP 538 Flex-Algorithm prefix capable routers when they participate in the 539 associated topology and algorithm. Forwarding entries for IP Flex- 540 Algorithm prefixes associated with Flex-Algorithms in which the node 541 is not participating MUST NOT be installed in the forwarding plane. 543 When the IP Flex-Algorithm prefix is associated with a Flex- 544 Algorithm, LFA paths to the prefix MUST be calculated using such 545 Flex-Algorithm in the associated topology, to guarantee that they 546 follow the same constraints as the calculation of the primary paths. 548 9. Deployment Considerations 550 IGP Flex-Algorithm can be used by many applications. Original 551 specification was done for SR and SRv6, this specification adds IP as 552 another application that can use IGP Flex-Algorithm. Other 553 applications may be defined in the future. This section provides 554 some details about the coexistence of the various applications of the 555 IGP Flex-Algorithm. 557 Flex-Algorithm definition (FAD), as described in 558 [I-D.ietf-lsr-flex-algo], is application independent and is used by 559 all Flex-Algorithm applications. 561 Participation in the Flex-Algorithm, as described in 562 [I-D.ietf-lsr-flex-algo], is application specific. 564 Calculation of the flex-algo paths is application specific and uses 565 application specific participation advertisements. 567 Application specific participation and calculation guarantee that the 568 forwarding of the traffic over the Flex-Algorithm application 569 specific paths is consistent between all nodes over which the traffic 570 is being forwarded. 572 Multiple application can use the same Flex-Algorithm value at the 573 same time and and as such share the FAD for it. For example SR-MPLS 574 and IP can both use such common Flex-Algorithm. Traffic for SR-MPLS 575 will be forwarded based on Flex-algorithm specific SR SIDs. Traffic 576 for IP Flex-Algorithm will be forwarded based on Flex-Algorithm 577 specific prefix reachability announcements. 579 10. Protection 581 In many networks where IGP Flexible Algorithms are deployed, IGP 582 restoration will be fast and additional protection mechanisms will 583 not be required. IGP restoration may be enhanced by Equal Cost 584 Multipath (ECMP). 586 In other networks, operators can deploy additional protection 587 mechanisms. The following are examples: 589 o Loop Free Alternates (LFA) [RFC5286] 591 o Remote Loop Free Alternates (R-LFA) [RFC7490] 593 LFA and R-LFA computations MUST be restricted to the flex-algo 594 topology and the computed backup nexthops should be programmed for 595 the IP flex-algo prefixes. 597 11. IANA Considerations 599 This specification updates the OSPF Router Information (RI) TLVs 600 Registry as follows: 602 +-------+------------------+---------------------------+ 603 | Value | TLV Name | Reference | 604 +-------+------------------+---------------------------+ 605 | TBD | IP Algorithm TLV | This Document Section 5.2 | 606 +-------+------------------+---------------------------+ 608 This document also updates the "Sub-TLVs for TLV 242" registry as 609 follows: 611 +-------+----------------------+---------------------------+ 612 | Value | TLV Name | Reference | 613 +-------+----------------------+---------------------------+ 614 | 29 | IP Algorithm Sub-TLV | This Document Section 5.1 | 615 +-------+----------------------+---------------------------+ 617 This document also updates the "ISIS TLV Codepoints Registry" 618 registry as follows: 620 +-------+------------------+-----+-----+-----+-------+--------------+ 621 | Value | TLV Name | IIH | LSP | SNP | Purge | Reference | 622 +-------+------------------+-----+-----+-----+-------+--------------+ 623 | 126 | IPv4 Algorithm | N | Y | N | N | This | 624 | | Prefix | | | | | document, | 625 | | Reachability TLV | | | | | Section 6.1 | 626 | 127 | IPv6 Algorithm | N | Y | N | N | This | 627 | | Prefix | | | | | document, | 628 | | Reachability TLV | | | | | Section 6.2 | 629 +-------+------------------+-----+-----+-----+-------+--------------+ 631 This document updates the "OSPFv2 Extended Prefix Opaque LSA TLVs" 632 registry as follows:: 634 +-------+----------------------------------+------------------------+ 635 | Value | TLV Name | Reference | 636 +-------+----------------------------------+------------------------+ 637 | TBD | OSPFv2 Algorithm Prefix | This Document, | 638 | | Reachability TLV | Section 6.1 | 639 +-------+----------------------------------+------------------------+ 641 12. Security Considerations 643 TBD 645 13. Acknowledgements 647 TBD. 649 14. References 651 14.1. Normative References 653 [I-D.ietf-lsr-flex-algo] 654 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 655 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 656 algo-14 (work in progress), February 2021. 658 [ISO10589] 659 IANA, "Intermediate system to Intermediate system routing 660 information exchange protocol for use in conjunction with 661 the Protocol for providing the Connectionless-mode Network 662 Service (ISO 8473)", August 1987, . 664 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 665 DOI 10.17487/RFC0791, September 1981, 666 . 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, 670 DOI 10.17487/RFC2119, March 1997, 671 . 673 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 674 DOI 10.17487/RFC2328, April 1998, 675 . 677 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 678 (TE) Extensions to OSPF Version 2", RFC 3630, 679 DOI 10.17487/RFC3630, September 2003, 680 . 682 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 683 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 684 RFC 4915, DOI 10.17487/RFC4915, June 2007, 685 . 687 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 688 Topology (MT) Routing in Intermediate System to 689 Intermediate Systems (IS-ISs)", RFC 5120, 690 DOI 10.17487/RFC5120, February 2008, 691 . 693 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 694 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 695 2008, . 697 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 698 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 699 . 701 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 702 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 703 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 704 2015, . 706 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 707 S. Shaffer, "Extensions to OSPF for Advertising Optional 708 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 709 February 2016, . 711 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 712 for Advertising Router Information", RFC 7981, 713 DOI 10.17487/RFC7981, October 2016, 714 . 716 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 717 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 718 May 2017, . 720 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 721 (IPv6) Specification", STD 86, RFC 8200, 722 DOI 10.17487/RFC8200, July 2017, 723 . 725 14.2. Informative References 727 [I-D.ietf-spring-srv6-network-programming] 728 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 729 Matsushima, S., and Z. Li, "SRv6 Network Programming", 730 draft-ietf-spring-srv6-network-programming-28 (work in 731 progress), December 2020. 733 [IANA-ALG] 734 IANA, "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY 735 TLV)", August 1987, . 738 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 739 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 740 DOI 10.17487/RFC5286, September 2008, 741 . 743 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 744 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 745 RFC 7490, DOI 10.17487/RFC7490, April 2015, 746 . 748 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 749 Decraene, B., Litkowski, S., and R. Shakir, "Segment 750 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 751 July 2018, . 753 Authors' Addresses 754 William Britto 755 Juniper Networks 756 Elnath-Exora Business Park Survey 757 Bangalore, Karnataka 560103 758 India 760 Email: bwilliam@juniper.net 762 Shraddha Hegde 763 Juniper Networks 764 Elnath-Exora Business Park Survey 765 Bangalore, Karnataka 560103 766 India 768 Email: shraddha@juniper.net 770 Parag Kaneriya 771 Juniper Networks 772 Elnath-Exora Business Park Survey 773 Bangalore, Karnataka 560103 774 India 776 Email: pkaneria@juniper.net 778 Rejesh Shetty 779 Juniper Networks 780 Elnath-Exora Business Park Survey 781 Bangalore, Karnataka 560103 782 India 784 Email: mrajesh@juniper.net 786 Ron Bonica 787 Juniper Networks 788 2251 Corporate Park Drive 789 Herndon, Virginia 20171 790 USA 792 Email: rbonica@juniper.net 793 Peter Psenak 794 Cisco Systems 795 Apollo Business Center 796 Mlynske nivy 43, Bratislava 82109 797 Slovakia 799 Email: ppsenak@cisco.com