idnits 2.17.1 draft-hegdeppsenak-isis-sr-flex-algo-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 (October 23, 2017) is 2374 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) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Psenak, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Hegde, Ed. 5 Expires: April 26, 2018 Juniper Networks, Inc. 6 C. Filsfils 7 Cisco Systems, Inc. 8 A. Gulko 9 Thomson Reuters 10 October 23, 2017 12 ISIS Segment Routing Flexible Algorithm 13 draft-hegdeppsenak-isis-sr-flex-algo-01.txt 15 Abstract 17 IGP protocols traditionally compute best paths over the network based 18 on the IGP metric assigned to the links. Many network deployments 19 use RSVP based or Segment Routing based Traffic Engineering to 20 enforce traffic over a path that is computed using different metrics 21 or constrains then IGP path. Various mechanisms are used to steer 22 the traffic towards such traffic engineered paths. This document 23 proposes a solution that allows IGPs itself to compute constrained 24 based path over the network without the usage of the traffic 25 engineering. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 26, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 63 2. Flexible Algorithm . . . . . . . . . . . . . . . . . . . . . 3 64 3. Flexible Algorithm Advertisement . . . . . . . . . . . . . . 3 65 4. Flexible Algorithm Definition Advertisement . . . . . . . . . 4 66 4.1. Flexible Algorithm Definition TLV . . . . . . . . . . . . 4 67 4.2. Flexible Algorithm Exclude Admin Group Sub-TLV . . . . . 7 68 5. Calculation of Flexible Algorithm Paths . . . . . . . . . . . 7 69 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 9 73 8.2. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 9 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 10.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 IGP computed path based on the shortest IGP metric must often be 83 replaced by traffic engineered path due to the traffic requirements 84 which are not reflected in the IGP metric. Some networks engineer 85 the IGP metric assignments in a way that the IGP Metric reflects the 86 link bandwidth or delay. If, for example, the IGP metric is 87 reflecting the bandwidth on the link and the application traffic is 88 delay sensitive, the best IGP path may not reflect the best path from 89 such application's perspective. 91 To overcome such IGP limitation, various sorts of traffic engineering 92 has been deployed, including RSVP-TE or SR-TE, in which case the TE 93 component is responsible for computing the path based on some other 94 or additional metrics and/or constrains. Such paths need to be 95 installed in the forwarding and replace the original paths computed 96 by IGPs. Tunnels are often used to represent the engineered paths 97 and mechanisms like one described in [RFC3906] are used to replace 98 the native IGP paths with such tunnel paths. 100 Segment Routing (SR) allows a flexible definition of end-to-end paths 101 within IGP topologies by encoding paths as sequences of topological 102 sub-paths, called segments. It also defines an algorithm that 103 defines how the path is computed. It also provides a way to 104 associate Prefix-SID with an algorithm. This allows IGPs to compute 105 the path based on various algorithms and forward the traffic on a 106 such path using the algorithm specific segments. 108 This document describes the IS-IS extension to support Segment 109 Routing Flexible Algorithm on an MPLS data-plane. 111 1.1. Requirements notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Flexible Algorithm 119 Many possible constrains may be used to compute a path over a 120 network. Some networks are deployed as multiple planes. A simple 121 form of constrain may be to use a particular plane. A more 122 sophisticated form of constrain can include some extended metric as 123 described in [RFC7810]. Even more advanced case could be to restrict 124 the path and avoid links with certain affinities. Combinations of 125 these are also possible. 127 To provide a maximum flexibility we do not want to provide a strict 128 mapping between the set of constrains and the algorithm that is 129 associated with it. We want the mapping between the algorithm value 130 and it's meaning to be flexible and defined by the user. As far as 131 all routers in the domain has the common understanding what the 132 particular algorithm value represents, the computation for such 133 algorithm is consistent and traffic is not subject to the looping. 135 Because the meaning of the algorithm is not defined by any standard, 136 but is defined by the user, we call it Flex-Algorithm. 138 3. Flexible Algorithm Advertisement 140 [I-D.ietf-isis-segment-routing-extensions] defines an SR-Algorithm. 141 This algorithm defines how the best path is computed by IGP. Routers 142 advertise the support for the algorithm as a node capability. Prefix 143 SIDs are also advertised with an algorithm value and as such are 144 tightly coupled with the algorithm. 146 Existing advertisement of the SR-Algorithm is used for the Flex- 147 Algorithm advertisements as defined in 148 [I-D.ietf-isis-segment-routing-extensions]. 150 SR-Algorithm is a one octet value. We propose to split the range of 151 values as follows: 153 0-127 - standardised values provided by IANA 155 128-255 - user defined values. 157 4. Flexible Algorithm Definition Advertisement 159 To guarantee the loop free forwarding for paths computed for a 160 particular Flex-Algorithm, all routers in the network MUST share the 161 same definition of the Flex-Algorithm. This can be achieved by each 162 router advertising its definition of each Flex-Algorithm that is 163 locally defined and detect any conflicts in the Flex-Algorithm 164 definition between routers. 166 Alternatively, the central entity in the network can advertise the 167 definition of the Flex-Algorithm and let all routers to use it. 169 Two definitions of the Flex-Algorithm are considered to match if all 170 of the following conditions are met: 172 Metric Type for both definitions is the same. 174 The set of Admin Groups that are excluded is exactly the same in 175 both definitions. 177 4.1. Flexible Algorithm Definition TLV 179 Flexible Algorithm Definition TLV (FAD TLV) is used to advertise the 180 definition of the Flex-Algorithm. 182 FAD TLV can be advertised as: 184 Sub-TLV of the IS-IS Router Capability TLV-242 that is defined in 185 [RFC7981]. When advertised as Sub-TLV of the IS-IS Router 186 Capability TLV-242, it is used to advertise the local definition 187 of the Flex-Algorithm on the originating router. 189 ISIS top-level TLV. When advertised as top-level TLV, it is used 190 to inform routers in entire domain about the definition of the 191 Flex-Algorithm. 193 When the definition of the Flex Algorithm is advertised, ether in the 194 TLV-242 or in the new top-level TLV, it is is applicable to all 195 topologies supported on the receiving node. 197 FAD TLV has the following format: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | Flags | Algorithm | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Metric Type | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Flex-Algorithm Exclude sub-TLVs | 207 +- -+ 208 | ... | 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 where: 215 Type: 217 When advertised as Sub-TLV of the IS-IS Router Capability TLV- 218 242: TBD1 220 When advertised as ISIS top-level TLV: TBD2 222 Length: variable, dependent on the number of Sub-TLVs 224 Flags: Single octet field containing the following flags: 226 0 1 2 3 4 5 6 7 227 +-+-+-+-+-+-+-+-+ 228 |S|D| | 229 +-+-+-+-+-+-+-+-+ 231 where: 233 S-Flag: If set, the FAD top-level TLV SHOULD be flooded across 234 the entire routing domain. If the S flag is not set, the FAD 235 TLV MUST NOT be leaked between levels. This bit MUST NOT be 236 altered during the TLV leaking. This bit MUST be ignored in 237 the FAD Sub-TLV of the IS-IS Router Capability TLV-242. 239 D-Flag: when the FAD top-level TLV is leaked from level-2 to 240 level-1, the D bit MUST be set. Otherwise, this bit MUST be 241 clear. FAD top-level TLVs with the D bit set MUST NOT be 242 leaked from level-1 to level-2. This is to prevent TLV looping 243 across levels. This bit MUST be ignored in the FAD Sub-TLV of 244 the IS-IS Router Capability TLV-242. 246 Algorithm: Flex-Algorithm number. Value between 128 and 255 247 inclusive. 249 Metric Type: Type of metric to be used during the calculation. 250 Following values are defined: 252 0: IGP Metric 254 1: Min Unidirectional Link Delay as defined in [RFC7810]. 256 2: TE metric as defined in [RFC5305]. 258 Flex-Algorithm Exclude sub-TLVs - optional sub-TLVs as described 259 in section Section 4.2. 261 When the router is configured with the local definition of the Flex- 262 Algorithm, the router SHOULD advertise its local definition in the 263 FAD Sub-TLV of the IS-IS Router Capability TLV-242. If the local 264 definition of the Flex-Algorithm is not advertised, the inconsistency 265 in the configuration of the Flex-Algorithm on various nodes can not 266 be detected and traffic routed based on a Flex-Algorithm path may 267 loop permanently. 269 When the router receives the FAD TLV as top-level TLV, it uses it as 270 a definition of the Flex-Algorithm. If the local definition of the 271 same Flex-Algorithm exists on the router and is in conflict with the 272 definition received over top-level FAD TLV, the router MUST NOT 273 compute any path for such Flex-Algorithm and MUST stop advertising 274 support for such Flex-Algorithm in its SR-Algorithm Sub-TLV 275 ([I-D.ietf-isis-segment-routing-extensions]). 277 When router receives the FAD Sub-TLV of the IS-IS Router Capability 278 TLV-242 from multiple sources and the Flex-Algorithm definition in 279 these advertisements are conflicting, it MUST NOT compute any path 280 for such Flex-Algorithm and MUST stop advertising support for such 281 Flex-Algorithm in its SR-Algorithm Sub-TLV 282 ([I-D.ietf-isis-segment-routing-extensions]). 284 When router receives the FAD Sub-TLV of the IS-IS Router Capability 285 TLV-242 from another router and the definition is in conflict with 286 either the local definition of the Flex-Algorithm OR the definition 287 received in the FAD top-level TLV, it MUST NOT compute any path for 288 such Flex-Algorithm. 290 The FAD Sub-TLV of the IS-IS Router Capability TLV-242 MUST be 291 propagated throughout the level and MUST be advertised across level 292 boundaries. Therefore Router Capability TLV distribution flags 293 SHOULD be set accordingly, i.e., the S flag in the Router Capability 294 TLV MUST be set. 296 4.2. Flexible Algorithm Exclude Admin Group Sub-TLV 298 To provide even more granularity, the Flexible-Algorithm can include 299 link 'colors' that the operator wants to exclude from the 300 computation. This provides a per link granularity for the Flex- 301 Algorithm definition. 303 Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV) is a 304 Sub-TLV of the FAD TLV. It has the following format: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Extended Admin Group | 312 +- -+ 313 | ... | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 where: 317 Type: TBD3 319 Length: variable, dependent on the size of the Extended Admin 320 Group. MUST be a multiple of 4 octets. 322 Extended Administrative Group: Extended Administrative Group as 323 defined in [RFC7308]. 325 FAEAG Sub-TLV SHOULD only appear once in FAD TLV. If it appears more 326 then once, FAD TLV MUST be ignored by the receiver. 328 5. Calculation of Flexible Algorithm Paths 330 A router may compute path for multiple Flex-Algorithms. 332 A router MUST be configured to support Flex-Algorithm K before it can 333 compute any path for Flex-Algorithm K. 335 A router MUST either be configured with a local definition of Flex- 336 Algorithm K or receive the definition via the FAD top-level TLV as 337 described in Section 4.1 from the central entity that acts as the 338 Flex-Algorithm definition holder before it can compute any path for 339 Flex-Algorithm K. 341 If any conflicts in the Flex-Algorithm K definition exists, as 342 described in Section 4.1, the router MUST NOT compute any path for 343 Flex-Algorithm K. 345 When computing the Shortest Path Tree for Flex-Algorithm K, all nodes 346 that do not advertise support for Flex-Algorithm K in SR-Algorithm 347 Sub-TLV ([I-D.ietf-isis-segment-routing-extensions]), MUST be pruned 348 from the topology. 350 When computing the Shortest Path Tree for Flex-Algorithm K, any link 351 advertised with any of the corresponding bits in both (Extended) 352 Administrative Groups sub-TLV and FAEAG Sub-TLV set to 1, MUST be 353 pruned from the topology. 355 When computing the Shortest Path Tree for Flex-Algorithm K, router 356 MUST use the metric that is part of the Flex-Algorithm definition. 357 If the metric is not advertised for the particular link, such link 358 MUST be pruned from the topology. A metric of value 0 MUST NOT be 359 assumed in such case. 361 Flex-Algorithm K path to any prefix MUST be installed in the 362 forwarding using the Prefix-SID that was advertised for algorithm K. 363 If the Prefix SID for algorithm K is not known, Flex-Algorithm K path 364 to such prefix MUST NOT be installed in the forwarding. 366 Loop Free Alternate (LFA) paths for Flex-Algorithm K path MUST be 367 computed using the same constrains as the calculation of the primary 368 paths for Flex-Algorithm K. LFA path MUST only use Prefix-SIDs 369 advertised specifically for algorithm K to enforce the traffic over 370 such path. 372 Any Shortest Path Tree calculation is limited to a single area. Same 373 applies to Flex-Algorithm calculations. Given that the computing 374 router may not have the visibility to the topology of remote areas, 375 the Flex-Algorithm K path to inter-area prefix will only be computed 376 for the local area. The 'exit' L1/L2 router will be selected based 377 on the best path for the Flex-Algorithm K in the local area and such 378 'exit' L1/L2 router will be responsible to compute the best Flex- 379 Algorithm K path over the next area. This may produce end-to-end 380 path, which is not the best from the Flex-Algorithm K perspective. 381 If the best end-to-end path for Flex-Algorithm K needs to be used for 382 inter-area destinations, paths for such destinations need to be 383 computed by the entity that has the topological information about all 384 areas. 386 6. Backward Compatibility 388 This extension brings no new backward compatibility issues. 390 7. Security Considerations 392 This extension adds no new security considerations. 394 8. IANA Considerations 396 This documents request allocation for the following TLVs and subTLVs. 398 8.1. Sub TLVs for Type 242 400 This document makes the following registrations in the "sub-TLVs for 401 TLV 242" registry. 403 Type: TBD1 (suggested value 24). 405 Description: Flexible Algorithm Definition Sub-TLV. 407 Reference: This document (Section 4.1). 409 8.2. New TLV Codepoint and Sub-TLV registry 411 This document registers the following TLV: 413 Type: TBD2 (suggested value 151) 415 name: Flexible Algorithm Definition TLV. 417 IIH: no 419 LSP: yes 421 SNP: no 423 Purge: no 425 Reference: This document (Section 4.1). 427 This document creates the following sub-TLV Registry: 429 Registry: sub-TLVs for TLV 151 431 Registration Procedure: Expert review 433 Reference: This document (Section 4.1) 435 This document resisters following TLV in the "sub-TLVs for TLV 151" 436 registry 438 Type: TBD3, suggested value 1. 440 Description: Flexible Algorithm Exclude Admin Group Sub-TLV. 442 Reference: This document (Section 4.2). 444 9. Acknowledgments 446 This draft, among other things, is also addressing the problem that 447 the [I-D.gulkohegde-routing-planes-using-sr] was trying to solve. 448 All authors of that draft agreed to join this draft. 450 Thanks to Les Ginsberg for review and useful comments on the initial 451 version of the draft. 453 Thanks to Cengiz Halit for his review and feedback during initial 454 phase of the solution definition. 456 10. References 458 10.1. Normative References 460 [I-D.ietf-isis-segment-routing-extensions] 461 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 462 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 463 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 464 segment-routing-extensions-13 (work in progress), June 465 2017. 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, 469 DOI 10.17487/RFC2119, March 1997, 470 . 472 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 473 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 474 2008, . 476 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 477 Traffic Engineering (MPLS-TE)", RFC 7308, 478 DOI 10.17487/RFC7308, July 2014, 479 . 481 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 482 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 483 RFC 7810, DOI 10.17487/RFC7810, May 2016, 484 . 486 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 487 for Advertising Router Information", RFC 7981, 488 DOI 10.17487/RFC7981, October 2016, 489 . 491 10.2. Informative References 493 [I-D.gulkohegde-routing-planes-using-sr] 494 Hegde, S. and a. arkadiy.gulko@thomsonreuters.com, 495 "Separating Routing Planes using Segment Routing", draft- 496 gulkohegde-routing-planes-using-sr-00 (work in progress), 497 March 2017. 499 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 500 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 501 RFC 3906, DOI 10.17487/RFC3906, October 2004, 502 . 504 Authors' Addresses 506 Peter Psenak (editor) 507 Cisco Systems 508 Apollo Business Center 509 Mlynske nivy 43 510 Bratislava, 82109 511 Slovakia 513 Email: ppsenak@cisco.com 515 Shraddha Hegde (editor) 516 Juniper Networks, Inc. 517 Embassy Business Park 518 Bangalore, KA, 560093 519 India 521 Email: shraddha@juniper.net 522 Clarence Filsfils 523 Cisco Systems, Inc. 524 Brussels 525 Belgium 527 Email: cfilsfil@cisco.com 529 Arkadiy Gulko 530 Thomson Reuters 532 Email: arkadiy.gulko@thomsonreuters.com