idnits 2.17.1 draft-peng-lsr-algorithm-related-adjacency-sid-00.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 (March 9, 2020) is 1509 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: 'RFC4915' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC8668' is defined on line 430, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-06 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR P. Shaofu 3 Internet-Draft C. Ran 4 Intended status: Standards Track ZTE Corporation 5 Expires: September 10, 2020 March 9, 2020 7 Algorithm Related IGP-Adjacency SID Advertisement 8 draft-peng-lsr-algorithm-related-adjacency-sid-00 10 Abstract 12 Segment Routing architecture supports the use of multiple routing 13 algorithms, i.e, different constraint-based shortest-path 14 calculations can be supported. There are two standard algorithms: 15 SPF and Strict-SPF, defined in Segment Routing architecture. There 16 are also other user defined algorithms according to Flex-algo 17 applicaiton. However, an algorithm identifier is often included as 18 part of a Prefix-SID advertisement, that maybe not satisfy some 19 scenarios where multiple algorithm share the same link resource. 20 This document will complement that the algorithm identifier can be 21 also included as part of a Adjacency-SID advertisement 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 10, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Adjacency Segment Identifier per Algorithm . . . . . . . . . 3 60 3.1. ISIS Adjacency Segment Identifier per Algorithm . . . . . 3 61 3.1.1. ISIS Adjacency Segment Identifier (Adj-SID) per 62 Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 4 63 3.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per 64 Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 4 65 3.2. OSPF Adjacency Segment Identifier per Algorithm . . . . . 5 66 3.2.1. OSPF Adj-SID Sub-TLV . . . . . . . . . . . . . . . . 6 67 3.2.2. OSPF LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . 6 68 3.3. OSPFv3 Adjacency Segment Identifier per Algorithm . . . . 7 69 3.3.1. OSPFv3 Adj-SID Sub-TLV . . . . . . . . . . . . . . . 7 70 3.3.2. OSPFv3 LAN Adj-SID Sub-TLV . . . . . . . . . . . . . 8 71 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Segment Routing architecture [RFC8402] supports the use of multiple 81 routing algorithms, i.e, different constraint-based shortest-path 82 calculations can be supported. There are two standard algorithms, 83 i.e, SPF and Strict-SPF, that defined in Segment Routing 84 architecture. For SPF, the packet is forwarded along the well known 85 ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs. 86 However, it is explicitly allowed for a midpoint to implement another 87 forwarding based on local policy. For Strict Shortest Path First 88 (Strict-SPF), it mandates that the packet be forwarded according to 89 the ECMP-aware SPF algorithm and instructs any router in the path to 90 ignore any possible local policy overriding the SPF decision. 92 There are also other user defined algorithms according to IGP Flex 93 Algorithm [I-D.ietf-lsr-flex-algo]. IGP Flex Algorithm proposes a 94 solution that allows IGPs themselves to compute constraint based 95 paths over the network, and it also specifies a way of using Segment 96 Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the 97 constraint-based paths. It specifies a set of extensions to ISIS, 98 OSPFv2 and OSPFv3 that enable a router to send TLVs that identify (a) 99 calculation-type, (b) specify a metric-type, and (c )describe a set 100 of constraints on the topology, that are to be used to compute the 101 best paths along the constrained topology. A given combination of 102 calculation-type, metric-type, and constraints is known as an FAD 103 (Flexible Algorithm Definition). 105 However, an algorithm identifier is often included as part of a 106 Prefix-SID advertisement, that maybe not satisfy some scenarios where 107 multiple algorithm share the same link resource. For example, a SR- 108 TE policy may be instantiated within specific Flex-algo plane, i.e., 109 the SID list requires to include algorithm related SIDs. An 110 algorithm-unware Adjacency-SID included in the SID list can just 111 steer the packet towards the link, but can not apply different QoS 112 policy for different algorithm. Another example is that the TI-LFA 113 backup path computed in Flex-algo plane may also contain an 114 algorithm-unware Adjacency-SID, which maybe also used in other SR-TE 115 instance. 117 This document will complement that the algorithm identifier can be 118 also included as part of an Adjacency-SID advertisement for SR-MPLS. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 3. Adjacency Segment Identifier per Algorithm 130 3.1. ISIS Adjacency Segment Identifier per Algorithm 132 [RFC8667] describes the IS-IS extensions that need to be introduced 133 for Segment Routing operating on an MPLS data plane. It defined 134 Adjacency Segment Identifier (Adj-SID) sub-TLV advertised with TLV- 135 22/222/23/223/141, and Adjacency Segment Identifier (LAN-Adj-SID) 136 Sub-TLV advetised with TLV-22/222/23/223. Accordingly, this document 137 defines two new optional Sub-TLVs, "ISIS Adjacency Segment Identifier 138 (Adj-SID) per Algorithm Sub-TLV" and "ISIS Adjacency Segment 139 Identifier (LAN-Adj-SID) per Algorithm Sub-TLV". 141 3.1.1. ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub- 142 TLV 144 ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub-TLV has 145 the following format: 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Type | Length | Flags | Weight | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Algorithm | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | SID/Label/Index (variable) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 1: ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm 158 Format 160 where: 162 Type: TBD1. 164 Length: 6 or 7 depending on size of the SID. 166 Flags: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV. 168 Weight: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV. 170 Algorithm: The Algorithm field contains the identifier of the 171 algorithm the router uses to apply algorithm specific QoS policy 172 configured on the adjacency. 174 SID/Label/Index: Refer to Adjacency Segment Identifier (Adj-SID) sub- 175 TLV. 177 For a P2P link, an SR-capable router MAY allocate different Adj-SID 178 for different algorithm, if this link will join different algorithm 179 related plane. 181 3.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm 182 Sub-TLV 184 ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm Sub-TLV 185 has the following format: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Type | Length | Flags | Weight | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Algorithm | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Neighbor System-ID (ID length octets) | 195 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | SID/Label/Index (variable) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 2: ISIS Adjacency Segment Identifier (LAN-Adj-SID) per 204 Algorithm Format 206 where: 208 Type: TBD2. 210 Length: Variable. 212 Flags: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV. 214 Weight: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV. 216 Algorithm: The Algorithm field contains the identifier of the 217 algorithm the router uses to apply algorithm specific QoS policy 218 configured on the adjacency. 220 SID/Label/Index: Refer to Adjacency Segment Identifier (LAN-Adj-SID) 221 Sub-TLV. 223 For a broadcast link, an SR-capable router MAY allocate different 224 Adj-SID for different algorithm, if this link will join different 225 algorithm related plane. 227 3.2. OSPF Adjacency Segment Identifier per Algorithm 229 [RFC8665] describes the OSPF extensions that need to be introduced 230 for Segment Routing operating on an MPLS data plane. It defined Adj- 231 SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Extended Link TLV 232 defined in [RFC7684]. This document extends these two Sub-TLVs to 233 carry the specific algorithm. 235 3.2.1. OSPF Adj-SID Sub-TLV 237 The existing Adj-SID Sub-TLV has the following format: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Flags | Algorithm | MT-ID | Weight | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | SID/Label/Index (variable) | 247 +---------------------------------------------------------------+ 249 Figure 3: OSPF Adj-SID Format 251 where: 253 Algorithm: The new Algorithm field contains the identifier of the 254 algorithm the router uses to apply algorithm specific QoS policy 255 configured on the adjacency. 257 For a P2P link, an SR-capable router MAY allocate different Adj-SID 258 for different algorithm, if this link will join different algorithm 259 related plane. 261 3.2.2. OSPF LAN Adj-SID Sub-TLV 263 The existing LAN Adj-SID Sub-TLV has the following format: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Flags | Algorithm | MT-ID | Weight | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Neighbor ID | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | SID/Label/Index (variable) | 275 +---------------------------------------------------------------+ 277 Figure 4: OSPF LAN Adj-SID Format 279 where: 281 Algorithm: The new Algorithm field contains the identifier of the 282 algorithm the router uses to apply algorithm specific QoS policy 283 configured on the adjacency. 285 For a broadcast link, an SR-capable router MAY allocate different 286 Adj-SID for different algorithm, if this link will join different 287 algorithm related plane. 289 3.3. OSPFv3 Adjacency Segment Identifier per Algorithm 291 [RFC8666] describes the OSPFv3 extensions that need to be introduced 292 for Segment Routing operating on an MPLS data plane. It defined Adj- 293 SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Router-Link TLV 294 as defined in [RFC8362]. This document extends these two Sub-TLVs to 295 carry the specific algorithm. 297 3.3.1. OSPFv3 Adj-SID Sub-TLV 299 The existing Adj-SID Sub-TLV has the following format: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Flags | Weight | Algorithm | Reserved | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | SID/Label/Index (variable) | 309 +---------------------------------------------------------------+ 311 Figure 5: OSPFv3 Adj-SID Format 313 where: 315 Algorithm: The new Algorithm field contains the identifier of the 316 algorithm the router uses to apply algorithm specific QoS policy 317 configured on the adjacency. 319 For a P2P link, an SR-capable router MAY allocate different Adj-SID 320 for different algorithm, if this link will join different algorithm 321 related plane. 323 3.3.2. OSPFv3 LAN Adj-SID Sub-TLV 325 The existing LAN Adj-SID Sub-TLV has the following format: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Flags | Weight | Algorithm | Reserved | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Neighbor ID | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | SID/Label/Index (variable) | 337 +---------------------------------------------------------------+ 339 Figure 6: OSPFv3 LAN Adj-SID Format 341 where: 343 Algorithm: The new Algorithm field contains the identifier of the 344 algorithm the router uses to apply algorithm specific QoS policy 345 configured on the adjacency. 347 For a broadcast link, an SR-capable router MAY allocate different 348 Adj-SID for different algorithm, if this link will join different 349 algorithm related plane. 351 4. Operations 353 TBD 355 5. IANA Considerations 357 TBD 359 6. Security Considerations 361 There are no new security issues introduced by the extensions in this 362 document. 364 7. Acknowledgements 366 TBD 368 8. Normative References 370 [I-D.ietf-lsr-flex-algo] 371 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 372 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 373 algo-06 (work in progress), February 2020. 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, 377 DOI 10.17487/RFC2119, March 1997, 378 . 380 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 381 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 382 RFC 4915, DOI 10.17487/RFC4915, June 2007, 383 . 385 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 386 Topology (MT) Routing in Intermediate System to 387 Intermediate Systems (IS-ISs)", RFC 5120, 388 DOI 10.17487/RFC5120, February 2008, 389 . 391 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 392 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 393 . 395 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 396 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 397 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 398 2015, . 400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 402 May 2017, . 404 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 405 F. Baker, "OSPFv3 Link State Advertisement (LSA) 406 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 407 2018, . 409 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 410 Decraene, B., Litkowski, S., and R. Shakir, "Segment 411 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 412 July 2018, . 414 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 415 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 416 Extensions for Segment Routing", RFC 8665, 417 DOI 10.17487/RFC8665, December 2019, 418 . 420 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 421 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 422 December 2019, . 424 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 425 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 426 Extensions for Segment Routing", RFC 8667, 427 DOI 10.17487/RFC8667, December 2019, 428 . 430 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 431 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 432 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 433 December 2019, . 435 Authors' Addresses 437 Peng Shaofu 438 ZTE Corporation 439 No.68 Zijinghua Road, Yuhuatai District 440 Nanjing 441 China 443 Email: peng.shaofu@zte.com.cn 445 Chen Ran 446 ZTE Corporation 447 No.50 Software Avenue, Yuhuatai District 448 Nanjing 449 China 451 Email: chen.ran@zte.com.cn