idnits 2.17.1 draft-bonica-lsr-ip-flexalgo-01.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 (November 15, 2020) is 1258 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 652, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 676, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 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: May 19, 2021 R. Shetty 6 R. Bonica 7 Juniper Networks 8 P. Psenak 9 Cisco Systems 10 November 15, 2020 12 IGP Flexible Algorithms (Flex-Algorithm) In IP Networks 13 draft-bonica-lsr-ip-flexalgo-01 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 May 19, 2021. 43 Copyright Notice 45 Copyright (c) 2020 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 13.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 An IGP Flex-Algorithm as specified in [I-D.ietf-lsr-flex-algo] 86 computes a constraint-based path to: 88 o All Flex-Algorithm specific Prefix Segment Identifiers (SIDs) 89 [RFC8402]. 91 o All Flex-Algorityhm specific SRv6 Locators 92 [I-D.ietf-spring-srv6-network-programming]. 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 98 to: 100 o An IPv4 [RFC0791] address. 102 o An IPv6 [RFC8200] address. 104 This allows Flex-Algorithm to be deployed in any IP network, even in 105 the absence of SR and SRv6. 107 2. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 3. Egress Node Procedures 117 Network operators configure multiple loopback interfaces on an egress 118 node. They associate one or more IP addresses with each loopback 119 interface and one Flex-Algorithm with each IP address. 121 If a packet is sent to a loopback address, and the loopback address 122 is not associated with a Flex-Algorithm, the packet follows the IGP 123 least-cost path to the egress node. If a packet is sent to a 124 loopback address, and the loopback address is associated with a Flex- 125 Algorithm, the packet follows the constraint-base path that the Flex- 126 Algorithm calculated. 128 4. Advertising Flex-Algorithm Definitions (FAD) 130 To guarantee loop free forwarding, all routers that participate in a 131 Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD). 133 Selected nodes within the IGP domain MUST advertise FADs as described 134 in Sections 5, 6 and 7 of [I-D.ietf-lsr-flex-algo]. 136 5. Advertising IP Flex-Algorithm Participation 138 A node may use various algorithms when calculating paths to nodes and 139 prefixes. Algorithm values are defined in the IGP Algorithm Type 140 Registry [IANA-ALG]. 142 A node MUST participate in a Flex-Algorithm to be: 144 o able to compute path for such Flex-Algorithm 145 o be part of the topology for such Flex-Algorithm 147 Flex-Algorithm participation MUST be advertised for each Flex- 148 Algorithm application independently, as specified in Section 10.2 of 149 [I-D.ietf-lsr-flex-algo]. Using Flex-Algorithm for regular IPv4 and 150 IPv6 prefixes represents a new Flex-Algorithm application (IP Flex- 151 Algorithm), and as such the Flex-Algorithm participation for the IP 152 Flex-Algorithm application MUST be signalled independently of any 153 other Flex-Algorithm applications (e.g. SR). 155 Following sections describe how the IP Flex-Algorithm participation 156 is advertised in IGP protocols. 158 5.1. The ISIS IP Algorithm Sub-TLV 160 The ISIS IP Algorithm Sub-TLV is a sub-TLV of the ISIS Router 161 Capability TLV [RFC7981] and has the following format: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: ISIS IP Algorithm Sub-TLV 173 o Type: IP Algorithm Sub-TLV (Value TBD by IANA) 175 o Length: Variable 177 o Algorithm (1 octet): value from 1 to 255. 179 The IP Algorithm Sub-TLV MUST be propagated throughout the level and 180 MUST NOT be advertised across level boundaries. Therefore, the S bit 181 in the Router Capability TLV, in which the IP Algorithm Sub-TLV is 182 advertised, MUST NOT be set. 184 The IP Algorithm Sub-TLV is optional. It MUST NOT be advertised more 185 than once at a given level. A router receiving multiple IP Algorithm 186 sub-TLVs from the same originator SHOULD select the first 187 advertisement in the lowest-numbered LSP and subsequent instances of 188 the IP Algorithm Sub-TLV MUST be ignored. 190 The IP Algorithm Sub-TLV advertises the participation in Flex- 191 Algorithms, and MUST NOT impact the router participation in default 192 algorithm 0. The IP Algorithm Sub-TLV could be used to advertise 193 support for non-zero standard algorithms, but that is outside the 194 scope of 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 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 1 to 255. 224 The IP Algorithm TLV is optional. It SHOULD only be advertised once 225 in 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 Algorithm TLV advertises the participation in Flex-Algorithms, 243 and MUST NOT impact the router participation in default algorithm 0. 244 The IP Algorithm TLV could be used to advertise support for non-zero 245 standard algorithms, but that is outside the scope of this document. 247 The IP Flex-Algorithm participation advertised in OSPF IP Algorithm 248 TLV is topology independent. When a router advertises participation 249 in OSPF IP Algorithm TLV, the participation applies to all topologies 250 in which the advertising node participates. 252 6. Advertising IP Flex-Algorthm Reachability 254 To be able to associate the prefix with the Flex-Algorithm, the 255 existing prefix reachability advertisements can not be used, because 256 they advertise the prefix reachability in default algorithm 0. 257 Instead, a new IP Flex-Algorithm reachability advertisements are 258 defined in ISIS and OSPF. 260 Two new top-level TLVs are defined in ISIS [ISO10589] to advertise 261 prefix reachability associated with a Flex-Algorithm. 263 o The IPv4 Algorithm Prefix Reachability TLV 265 o The IPv6 Algorithm Prefix Reachability TLV 267 New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684] is 268 defined to advertise prefix reachability associated with a Flex- 269 Algorithm in OSPFv2. 271 6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV 273 A new top level TLV is defined for advertising IPv4 Flex-Algorithm 274 Prefix Reachability in ISIS - IPv4 Algorithm Prefix Reachability TLV. 276 This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236 277 and 237. 279 The ISIS IPv4 Algorithm Prefix Reachability TLV has the following 280 format: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length |R|R|R|R| MTID | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 ISIS IPv4 Algorithm Prefix Reachability TLV 290 o Type: IPv4 Algorithm Prefix Reachability TLV (Value TBD by IANA). 292 o Length: variable. 294 o R bits (4 bits): reserved for future use. They MUST be set to 295 zero on transmission and MUST be ignored on receipt. 297 o MTID (12 bits): Multitopology Identifier as defined in [RFC5120]. 298 Note that the value 0 is legal. 300 Followed by one or more prefix entries of the form: 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Metric | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Flags | Algorithm | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Pfx Length | Prefix (variable)... 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Sub-tlv-len | Sub-TLVs (variable) . . . | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ISIS IPv4 Algorithm Prefix Reachability TLV 316 o Metric (4 octets): Metric information. 318 o Flags (1 octet): 320 0 1 2 3 4 5 6 7 321 +-+-+-+-+-+-+-+-+ 322 |D|S| | | 323 +-+-+-+-+-+-+-+-+ 325 D-flag: When the Prefix is leaked from level-2 to level-1, the 326 D bit MUST be set. Otherwise, this bit MUST be clear. 327 Prefixes with the D bit set MUST NOT be leaked from level-1 to 328 level-2. This is to prevent looping. 330 S-flag: Set when Sub-TLVs are present for the prefix entry. 332 o Algorithm (1 octet): Associated Algorithm from 1 to 255. 334 o Prefix Len (1 octet): Prefix length measured in bits. 336 o Prefix (variable length): Prefix mapped to Flex-Algorithm. 338 o Optional Sub-TLV-length (1 octet): Number of octets used by sub- 339 TLVs 341 o Optional sub-TLVs (variable length). 343 A router receiving multiple IPv4 Algorithm Prefix Reachability 344 advertisements for the same prefix, from the same originator, each 345 with a different Algorithm, MUST select the first advertisement in 346 the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm 347 Prefix Reachability advertisements for the same prefix for any other 348 Algorithm. 350 A router receiving multiple IPv4 Algorithm Prefix Reachability 351 advertisements for the same prefix, from different originators, each 352 with a different Algorithm, MUST ignore all of them and MUST NOT 353 install any forwarding entries based on these advertisements. 355 In cases where a prefix advertisement is received in both a IPv4 356 Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability 357 TLV, the IPv4 Prefix Reachability advertisement MUST be preferred 358 when installing entries in the forwarding plane. 360 6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV 362 The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the 363 ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a 364 unique type. The type is TBD by IANA. 366 A router receiving multiple IPv6 Algorithm Prefix Reachability 367 advertisements for the same prefix, from the same originator, each 368 with a different Algorithm, MUST select the first advertisement in 369 the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm 370 Prefix Reachability advertisements for the same prefix for any other 371 Algorithm. 373 A router receiving multiple IPv6 Algorithm Prefix Reachability 374 advertisements for the same prefix, from different originators, each 375 with a different Algorithm, MUST ignore all of them and MUST NOT 376 install any forwarding entries based on these advertisements. 378 In cases where a prefix advertisement is received in both a IPv6 379 Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability 380 TLV, the IPv6 Prefix Reachability advertisement MUST be preferred 381 when installing entries in the forwarding plane. 383 6.3. The OSPFv2 Algorithm Prefix Reachability TLV 385 A new top level TLV of OSPFv2 Extended Prefix Opaque LSA is defined 386 for advertising IPv4 Algorithm Prefix Reachability in OSPFv2 - OSPF 387 Algorithm Prefix Reachability TLV 389 Multiple Algorithm Prefix Reachability TLV MAY be advertised in each 390 OSPFv2 Extended Prefix Opaque LSA. However, since the opaque LSA 391 type defines the flooding scope, the LSA flooding scope MUST satisfy 392 the application specific requirements for all the prefixes included 393 in a single OSPFv2 Extended Prefix Opaque LSA. The Algorithm Prefix 394 Reachability TLV has the following format: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Route Type | Prefix Length | AF | Flags | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | MT-ID | Algorithm | Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Address Prefix (variable) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Metric | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Sub-TLVs (variable) | 410 +- -+ 411 | | 413 OSPFv2 Algorithm Prefix Reachability TLV 415 Type: Algorithm Prefix Reachability TLV (Value TBD by IANA). 417 Length: Variable dependent on sub-TLVs. 419 Route Type (1 octet): type of the OSPF route. Supported types 420 are: 422 1 - Intra-Area 423 2 - Inter-Area 425 3 - AS External with Type-1 Metric 427 4 - AS External with Type-2 Metric 429 5 - NSSA External with Type-1 Metric 431 6 - NSSA External with Type-2 Metric 433 Prefix Length (1 octet): Length of prefix in bits. 435 AF (1 octet): Address family for the prefix. Currently, the only 436 supported value is 0 for IPv4 unicast. The inclusion of address 437 family in this TLV allows for future extension. 439 Flags (1 octet): Flags applicable to the prefix. Supported Flags 440 include: 442 0x80 - A-Flag (Attach flag): An Area Border Router (ABR) 443 generating an Extended Prefix TLV for inter-area prefix that is 444 locally connected or attached in other connected area SHOULD 445 set this flag. 447 0x40 - N-Flag (Node Flag): Set when the prefix identifies the 448 advertising router i.e., the prefix is a host prefix 449 advertising a globally reachable address typically associated 450 with a loopback address. The advertising router MAY choose to 451 not set this flag even when the above conditions are met. If 452 the flag is set and the prefix length is not a host prefix then 453 the flag MUST be ignored. The flag is preserved when the 454 OSPFv2 Extended Prefix Opaque LSA is propagated between areas. 456 MT-ID (1 octet): Multi-Topology ID as defined in [RFC8402] 458 Algorithm: (1 octet). Associated Algorithm from 1 to 255. 460 Adress Prefix: For the address family IPv4 unicast, the prefix 461 itself encoded as a 32-bit value. The default route is 462 represented by a prefix of length 0. Prefix encoding for other 463 address families is beyond the scope of this specification. 465 Metric (4 octets): Metric information. 467 If this TLV is advertised multiple times for the same prefix in the 468 same OSPFv2 Extended Prefix Opaque LSA, only the first instance of 469 the TLV is used by receiving OSPFv2 Routers. This situation SHOULD 470 be logged as an error. 472 If this TLV is advertised multiple times for the same prefix in 473 different OSPFv2 Extended Prefix Opaque LSAs originated by the same 474 OSPF router, the OSPF advertising router is re-originating Extended 475 Prefix Opaque LSAs for multiple prefixes and is most likely repacking 476 Algorithm Prefix Reachability TLVs in Extended Prefix Opaque LSAs. 477 In this case, the Algorithm Prefix Reachability TLV in the Extended 478 Prefix Opaque LSA with the smallest Opaque ID is used by receiving 479 OSPFv2 Routers. This situation may be logged as a warning. 481 It is RECOMMENDED that OSPF routers advertising Algorithm Prefix 482 Reachability TLVs in different Extended Prefix Opaque LSAs re- 483 originate these LSAs in ascending order of Opaque ID to minimize the 484 disruption. 486 A router receiving multiple Algorithm Prefix Reachability TLVs for 487 the same prefix, from different originators, each with a different 488 Algorithm, MUST ignore all of them and MUST NOT install any 489 forwarding entries based on these advertisements. 491 In cases where a prefix advertisement is received in any of the LSAs 492 advertising the prefix reachability for algorithm 0 (Router-LSA, 493 Summary-LSA, AS-external-LSA or NSSA AS-external LSA) and in an IPv4 494 Algorithm Prefix Reachability TLV, the prefix reachability 495 advertisement for algorithm 0 MUST be preferred when installing 496 entries in the forwarding plane, regardless of the Route Type 497 advertised in IPv4 Algorithm Prefix Reachability TLV. 499 6.4. The OSPFv3 Flex-Algorithm IP Prefix Opaque LSA 501 TBD. 503 7. Calculating of IP Flex-Algorthm Paths 505 IP Flex-Algorthm is considered as yet another application of the 506 Flex-Algorithm as described in Section 10 and Section 12 of the 507 [I-D.ietf-lsr-flex-algo]. 509 Participation for the IP Flex-Algorithm is signalled as described in 510 Section 5 and is specific to the IP Flex-Algorithm application. 512 Calculation of IP Flex-Algorithm paths follows the Section 12 of 513 [I-D.ietf-lsr-flex-algo]. This computation uses the IP Flex- 514 Algorithm participation and is independent of the Flex-Algorithm 515 calculation done for any other Flex-Algorithm applications (e.g. SR, 516 SRv6). 518 IP Flex-Algorithm application only considers participating nodes 519 during the Flex-Algorithm calculation. When computing paths for a 520 given Flex-Algorithm, all nodes that do not advertise participation 521 for IP Flex-Algorithm, as described in Section 5, MUST be pruned from 522 the topology. 524 8. IP Flex-Algorthm Forwarding 526 IP Algorithm Prefix Reachability advertisement as described in 527 Section 5 includes the MTID value that associates the prefix with a 528 specific topology. Algorithm Prefix Reachability advertisement also 529 includes an Algorithm value that explicitly associates the prefix 530 with a specific Flex-Algorithm. The paths to the prefix MUST be 531 calculated using the specified Flex-Algorithm in the associated 532 topology. 534 Forwarding entries for the IP Flex-Algorithm prefixes advertised in 535 IGPs MUST be installed in the forwarding plane of the receiving IP 536 Flex-Algorithm prefix capable routers when they participate in the 537 associated topology and algorithm. Forwarding entries for IP Flex- 538 Algorithm prefixes associated with Flex-Algorithms in which the node 539 is not participating MUST NOT be installed in the forwarding plane. 541 When the IP Flex-Algorithm prefix is associated with a Flex- 542 Algorithm, LFA paths to the prefix MUST be calculated using such 543 Flex-Algorithm in the associated topology, to guarantee that they 544 follow the same constraints as the calculation of the primary paths. 546 9. Deployment Considerations 548 IGP Flex-Algorithm can be used by many applications. Original 549 specification was done for SR and SRv6, this specification adds IP as 550 another application that can use IGP Flex-Algorithm. Other 551 applications may be defined in the future. This section provides 552 some details about the coexistence of the various applications of the 553 IGP Flex-Algorithm. 555 Flex-Algorithm definition (FAD), as described in 556 [I-D.ietf-lsr-flex-algo], is application independent and is used by 557 all Flex-Algorithm applications. 559 Participation in the Flex-Algorithm, as described in 560 [I-D.ietf-lsr-flex-algo], is application specific. 562 Calculation of the flex-algo paths is application specific and uses 563 application specific participation advertisements. 565 Application specific participation and calculation guarantee that the 566 forwarding of the traffic over the Flex-Algorithm application 567 specific paths is consistent between all nodes over which the traffic 568 is being forwarded. 570 Multiple application can use the same Flex-Algorithm value at the 571 same time and and as such share the FAD for it. For example SR-MPLS 572 and IP can both use such common Flex-Algorithm. Traffic for SR-MPLS 573 will be forwarded based on Flex-algorithm specific SR SIDs. Traffic 574 for IP Flex-Algorithm will be forwarded based on Flex-Algorithm 575 specific prefix reachability announcements. 577 10. IANA Considerations 579 This specification updates the OSPF Router Information (RI) TLVs 580 Registry as follows: 582 +-------+------------------+---------------------------+ 583 | Value | TLV Name | Reference | 584 +-------+------------------+---------------------------+ 585 | TBD | IP Algorithm TLV | This Document Section 5.2 | 586 +-------+------------------+---------------------------+ 588 This document also updates the "Sub-TLVs for TLV 242" registry as 589 follows: 591 +-------+----------------------+---------------------------+ 592 | Value | TLV Name | Reference | 593 +-------+----------------------+---------------------------+ 594 | TBD | IP Algorithm Sub-TLV | This Document Section 5.1 | 595 +-------+----------------------+---------------------------+ 597 This document also updates the "ISIS TLV Codepoints Registry" 598 registry as follows: 600 +-------+----------------------------------+------------------------+ 601 | Value | TLV Name | Reference | 602 +-------+----------------------------------+------------------------+ 603 | TBD | IPv4 Algorithm Prefix | This document, | 604 | | Reachability TLV | Section 6.1 | 605 | TBD | IPv6 Algorithm Prefix | This document, | 606 | | Reachability TLV | Section 6.2 | 607 | TBD | 608 +-------+----------------------------------+------------------------+ 610 This document updates the "OSPFv2 Extended Prefix Opaque LSA TLVs" 611 registry as follows:: 613 +-------+----------------------------------+------------------------+ 614 | Value | TLV Name | Reference | 615 +-------+----------------------------------+------------------------+ 616 | TBD | OSPFv2 Algorithm Prefix | This Document, | 617 | | Reachability TLV | Section 6.1 | 618 +-------+----------------------------------+------------------------+ 620 11. Security Considerations 622 TBD 624 12. Acknowledgements 626 TBD. 628 13. References 630 13.1. Normative References 632 [I-D.ietf-lsr-flex-algo] 633 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 634 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 635 algo-13 (work in progress), October 2020. 637 [ISO10589] 638 IANA, "Intermediate system to Intermediate system routing 639 information exchange protocol for use in conjunction with 640 the Protocol for providing the Connectionless-mode Network 641 Service (ISO 8473)", August 1987, . 643 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 644 DOI 10.17487/RFC0791, September 1981, 645 . 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 653 DOI 10.17487/RFC2328, April 1998, 654 . 656 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 657 (TE) Extensions to OSPF Version 2", RFC 3630, 658 DOI 10.17487/RFC3630, September 2003, 659 . 661 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 662 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 663 RFC 4915, DOI 10.17487/RFC4915, June 2007, 664 . 666 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 667 Topology (MT) Routing in Intermediate System to 668 Intermediate Systems (IS-ISs)", RFC 5120, 669 DOI 10.17487/RFC5120, February 2008, 670 . 672 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 673 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 674 2008, . 676 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 677 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 678 . 680 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 681 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 682 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 683 2015, . 685 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 686 S. Shaffer, "Extensions to OSPF for Advertising Optional 687 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 688 February 2016, . 690 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 691 for Advertising Router Information", RFC 7981, 692 DOI 10.17487/RFC7981, October 2016, 693 . 695 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 696 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 697 May 2017, . 699 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 700 (IPv6) Specification", STD 86, RFC 8200, 701 DOI 10.17487/RFC8200, July 2017, 702 . 704 13.2. Informative References 706 [I-D.ietf-spring-srv6-network-programming] 707 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 708 Matsushima, S., and Z. Li, "SRv6 Network Programming", 709 draft-ietf-spring-srv6-network-programming-24 (work in 710 progress), October 2020. 712 [IANA-ALG] 713 IANA, "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY 714 TLV)", August 1987, . 717 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 718 Decraene, B., Litkowski, S., and R. Shakir, "Segment 719 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 720 July 2018, . 722 Authors' Addresses 724 William Britto 725 Juniper Networks 726 Elnath-Exora Business Park Survey 727 Bangalore, Karnataka 560103 728 India 730 Email: bwilliam@juniper.net 732 Shraddha Hegde 733 Juniper Networks 734 Elnath-Exora Business Park Survey 735 Bangalore, Karnataka 560103 736 India 738 Email: shraddha@juniper.net 740 Parag Kaneriya 741 Juniper Networks 742 Elnath-Exora Business Park Survey 743 Bangalore, Karnataka 560103 744 India 746 Email: pkaneria@juniper.net 747 Rejesh Shetty 748 Juniper Networks 749 Elnath-Exora Business Park Survey 750 Bangalore, Karnataka 560103 751 India 753 Email: mrajesh@juniper.net 755 Ron Bonica 756 Juniper Networks 757 2251 Corporate Park Drive 758 Herndon, Virginia 20171 759 USA 761 Email: rbonica@juniper.net 763 Peter Psenak 764 Cisco Systems 765 Apollo Business Center 766 Mlynske nivy 43, Bratislava 82109 767 Slovakia 769 Email: ppsenak@cisco.com