idnits 2.17.1 draft-peng-lsr-flex-algo-opt-slicing-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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: ISIS AII of FAD Sub-TLV MAY NOT appear more then once in an ISIS FAD Sub-TLV. If it appears more then once, the ISIS FAD Sub-TLV MUST be ignored by the receiver. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: OSPF AII of FAD Sub-TLV MAY NOT appear more then once in an OSPF FAD TLV. If it appears more then once, the OSPF FAD TLV MUST be ignored by the receiver. -- The document date (September 5, 2020) is 1300 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 (-26) exists of draft-ietf-lsr-flex-algo-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-05) exists of draft-peng-lsr-flex-algo-l2bundles-02 == Outdated reference: A later version (-04) exists of draft-peng-teas-network-slicing-03 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L P. Shaofu 3 Internet-Draft C. Ran 4 Intended status: Standards Track ZTE Corporation 5 Expires: March 9, 2021 G. Mirsky 6 ZTE Corp. 7 September 5, 2020 9 IGP Flexible Algorithm Optimazition for Netwrok Slicing 10 draft-peng-lsr-flex-algo-opt-slicing-02 12 Abstract 14 IGP Flex Algorithm proposes a solution that allows IGPs themselves to 15 compute constraint based paths over the network, and it also 16 specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 17 locators to steer packets along the constraint-based paths. This 18 document extends the use of the IGP Flex Algorithm to to be more 19 suitable for network slicing scenarios. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 9, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. SR Policy Using Slice-based Resources . . . . . . . . . . . . 3 58 4. SR Policy Optimaztion with IGP Flex-algo . . . . . . . . . . 3 59 5. IGP Flex-algo Enhancement with AII . . . . . . . . . . . . . 5 60 5.1. Enhancement for TI-LFA . . . . . . . . . . . . . . . . . 5 61 5.2. Enhancement for Inter-domain . . . . . . . . . . . . . . 5 62 5.3. Enhancement for L2bundles . . . . . . . . . . . . . . . . 6 63 6. QoS Policy per AII/Algorithm . . . . . . . . . . . . . . . . 6 64 7. AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. ISIS AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . 7 66 7.2. OSPF AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . 8 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. ISIS IANA Considerations . . . . . . . . . . . . . . . . 8 69 8.2. OSPF IANA Considerations . . . . . . . . . . . . . . . . 9 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] proposes a solution that 78 allows IGPs themselves to compute constraint based paths over the 79 network, and it also specifies a way of using Segment Routing (SR) 80 Prefix-SIDs and SRv6 locators to steer packets along the constraint- 81 based paths. It specifies a set of extensions to ISIS, OSPFv2 and 82 OSPFv3 that enable a router to send TLVs that identify (a) 83 calculation-type, (b) specify a metric-type, and (c )describe a set 84 of constraints on the topology, that are to be used to compute the 85 best paths along the constrained topology. A given combination of 86 calculation-type, metric-type, and constraints is known as an FAD 87 (Flexible Algorithm Definition). 89 [I-D.peng-teas-network-slicing] proposes a solution to extend the 90 control plane of transport network to instantiate the Network Slice 91 Instance (NSI) in transport network. A new identifier, AII, instead 92 of existing TE affinity or other identifiers, is introduced to 93 represent a TN-slice and specify the dedicated resource for the TN- 94 slice. 96 This document extends the FAD of IGP Flex Algorithm to let IGPs 97 compute constraint based paths limited in specific TN-slice. 99 2. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. SR Policy Using Slice-based Resources 109 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 110 Policy and steering into an SR Policy. These apply equally to the 111 MPLS and IPv6 (known as SRv6) data plane instantiations of Segment 112 Routing with their respective representations of segments as SR-MPLS 113 SID and SRv6 SID as described in [RFC8402]. The color of SR policy 114 defines a TE purpose, which includes a set of constraints such as 115 bandwidth, delay, TE metric, etc. 117 The overlay service can select underlay SR policy according to a 118 meaningful color value. From the perspective of service, color is 119 the key to get the expected SLA, and it is a global administrative 120 configuration or setting that could be exchangeable between two 121 devices for SR policy on-demand next-hop triggering. The service 122 never concern whether the underlay network has been partitioned as 123 multi-domains, or multi-topologies. That is, color has not semantic 124 local within one domain, or one topology. Instead, any type of 125 resources such as topology, computation, storage could be selected by 126 the color template. In this sense, TN-slices are also high-level 127 resouces that could be selected by color template. A simple way to 128 achieve this is to contain the specific AII information in the color 129 template, to restrict the TE path to the corresponding TN-slice. 131 4. SR Policy Optimaztion with IGP Flex-algo 133 Indeed, FA-id defined in [I-D.ietf-lsr-flex-algo] is a short mapping 134 of SR policy color to optimaze segment stack depth for the IGP area 135 partial of the entire SR policy. The overlay service that want to be 136 carried over a particual SR-FA path must firstly let the SR policy 137 supplier know that requirement. There are two possible ways to map a 138 color to an FA-id. One is explicit mapping configuration within 139 color template, the other is dynamic to replace a long segment list 140 to a single FA segment by headend or controller once the creteria 141 contained in the color-template equal to that contained in FAD. 143 In addtion to the above mapping mode, merging mode is also possible. 144 In this case, the computation engine will combine the constraints 145 contained in the expanded FAD with other constraints in the color 146 template. This is to continue to iterate TE business in FA plane. 147 The iteration means the best-effort path itself within an FA plane is 148 exactly constraint based path, but operators can define more 149 constraints in that FA plane. The computed strict path can be 150 optimized to a loose path when a part of the strict path is 151 consistent with the algorithm based path, i.e, some consecutive 152 adjacency SIDs can be replaced with a single algorithm based prefix 153 SID. Note that the loose optimization in this case, i.e, an SR 154 policy created in FA plane, is similar with that when an SR policy is 155 created in physical network, and that is different with optimization 156 of segment stack depth using Flex-algo. 158 [I-D.ietf-lsr-flex-algo] described that application specific Flex- 159 Algorithm participation advertisements MAY be topology specific or 160 MAY be topology independent, and also emphasize that for Segment 161 Routing application, the Flex-Algorithm participation advertisement 162 is topology independent, i.e., when a router advertises participation 163 in an SR-Algorithm, the participation applies to all topologies in 164 which the advertising node participates. Here the topology means 165 Multi-Topology Routing (MTR) described in [RFC5120], [RFC4915], 166 [RFC5340]. [RFC8402] also mentioned that multiple SIDs MAY be 167 allocated to the same prefix so long as the tuple is unique. In fact, this will lead to many forwarding 169 tables, such as table per MTR, table per each combined tuple , and make traffic steering very complicated. 172 According to [I-D.peng-teas-network-slicing], we donot use MTR to 173 identify the TN-slice and partition the virtual topology for the TN- 174 slice. Instead, a slice-based identifier, AII, is introduced to 175 represent a TN-slice. The first feature of AII is a TE criteria for 176 TE service just like AG/EAG. So that AII, like other constraints, 177 can be included in color template. When an SR policy uses Flex-algo 178 for stack depth optimization, in order to make the contents of the 179 color template and the mapping FAD consistent, AII is also necessary 180 put into the mapping FAD. 182 Although the network operator may change the AII information within 183 the FAD for the specific FA-id, there is only one forwarding table 184 with constant table ID, i.e., FA-id. Note that there are also 185 independent forwarding tables per AII for other purpose, but not 186 those per tuple . That is, FA-id has not semantic local 187 within AII, just as color is not part of the topology. 189 5. IGP Flex-algo Enhancement with AII 191 FAD that contains AII information will enhance the capability of 192 Flex-algo to support network slicing. 194 5.1. Enhancement for TI-LFA 196 Loop Free Alternate (LFA) paths for a given Flex-Algorithm can 197 include Prefix-SIDs advertised specifically for the given algorithm, 198 and especially Adjacency-SIDs for the specific AII. When different 199 FA planes share the same link resouce, Adjacency-SID per AII 200 (according to [I-D.peng-teas-network-slicing]) can distinguish the 201 flow of different slices well and provide different treatment. 203 The following figure shows an example of Flex-algo enhancement with 204 AII. 206 [S1]--------[D]--------[S2] 207 | | | 208 | | | 209 | | | 210 [A]---------[B]--------[C] 212 Figure 1: Flex-algo LFA Enhancement with AII 214 Suppose that node S1, A, B, D and their inter-connected links belongs 215 to FA-id 128 plane as well as AII-1, and S2, B, C, D and their inter- 216 connected links belongs to FA-id 129 plane as well as AII-2. The IGP 217 metric of link B-D is 100, and all other links have IGP metric 1. In 218 FA-id 128 plane, from S1 to destination D, the primary path is S1-D, 219 and the TI-LFA backup path is segment list {node(B), adjacency(B-D)}. 220 Similarly, In FA-id 129 plane, from S2 to destination D, the primary 221 path is S2-D, and the TI-LFA backup path is segment list {node(B), 222 adjacency(B-D)}. With the help of AII parameter contained in the FAD, 223 the above TI-LFA path of FA-id 128 plane will be translated to {node- 224 SID(B)@FA-id128, adjacency-SID(B-D)@AII-1}, and TI-LFA path of FA-id 225 129 plane will be translate to {node-SID(B)@FA-id129, adjacency- 226 SID(B-D)@AII-2}. So that node B can distinguish the flow of FA-id 128 227 and FA-id 129 with different treatment (e.g., QoS) and send to the 228 same outgoing link B-D. 230 5.2. Enhancement for Inter-domain 232 For inter-domain case, different domain can config different FA-id 233 independently, but they can contain the same AII to construct an E2E 234 slice-based SR policy. IGP flex-algo is responsible for creating 235 constraint based paths within the domain according to FAD including 236 AII parameter, and BGP-LU or SDN controller is responsible for 237 selecting inter-domain links according to color template including 238 AII parameter. AII is easy to address the requirement of E2E Slicing 239 view. 241 5.3. Enhancement for L2bundles 243 [RFC8668] inroduced L2 Bundle Member Attributes sub-TLV to be 244 advertised within ISIS TLV-22/23/141/222/223. It may define an 245 attribute common to all of the bundle members listed and an attribute 246 individual to each L2 Bundle Member. [RFC8668] mainly defined 247 Adjacency-SID for each L2 Bundle Member, that is very useful to 248 isolate flows among different slices. A typical deployment of hard 249 slicing is that different L2 Bundle Member, e.g, Flex-E channel, 250 belongs to different TN-slice, so a specific Adjacency-SID for a 251 specific L2 Bundle Member will steer the packets to that member. 253 However, the link resource of an FA plane is selected according to 254 the TE affinity attribute of all L3 links joining to the IGP instance 255 and the INCLUDE/EXCLUDE rules contained in the FAD. If we want to 256 let different L2 Bundle Member belongs to different FA plane, it must 257 determine the TE affinity of each L2 Bundle Member. There could have 258 two methods: 260 o [I-D.zch-lsr-isis-network-slicing] extends ISIS protocol to carry 261 AII (TN-slice ID) information for each L2 Bundle Member within L2 262 Bundle Member Attributes sub-TLV defined in [RFC8668]. Even 263 though the same L3 parrent link can be joined to multiple FA 264 planes according to TE affinity INCLUDE/EXCLUDE rules, it is easy 265 for each FA plane to exactly use the specific L2 Bundle Member 266 according to the AII information contained in FAD. 268 o It is also possible to directly define AG/EGA per L2 Bundle Member 269 for Flex-algo application. [I-D.peng-lsr-flex-algo-l2bundles] 270 described how to create Flex-algo plane in the case of L2bundles 271 scenario, by explicit AG/EGA affinity configuration for each L2 272 Bundle Member. This method is similar with the above definition 273 of AII per L2 Bundle Member, both them can distinguish traffic of 274 different hard slice. 276 It is possible to include only AII, or only TE affinity, or both AII 277 and TE affinity, in an FAD. 279 6. QoS Policy per AII/Algorithm 281 Due to SID allocation per algorithm, flows belonging to different FA 282 planes can be easily distinguished by incoming SID of the received 283 packets, so that different QoS policies can be applied to different 284 FA packets on the same link. 286 Depending on the implementation, operators can configure multiple QoS 287 policies each for different algorithm on the same link. One of the 288 difficulties is that during this configuration phase it is not 289 straightforward for a link to be included in an FA plane, as this can 290 only be determined after all nodes in the network have negotiated the 291 FAD. A simple way is that as long as a node enable an FA, all its 292 links are configured with that algorithm based QoS policy. 294 Depending on the implementation, operators can also configure 295 multiple QoS policies each for different AII on the same link. An 296 AII based QoS policy is configured to a subset of links who join the 297 related TN-slice explicitly. 299 Depending on the implementation, the queue resources of the link can 300 be divided according to AII, algorithm, or their combination. When 301 the received pachet matched an flex-algo related FIB entry, it will 302 be directed to the queue dedicated to that algorithm. If the FIB 303 entry is created according to the FAD including AII creteria, the 304 packets can further schedule queue resouce according to AII. 306 7. AII of FAD Sub-TLV 308 7.1. ISIS AII of FAD Sub-TLV 310 ISIS AII of FAD Sub-TLV is used to advertise the AII information that 311 is used during the Flex-Algorithm path calculation. It is a Sub-TLV 312 of the ISIS FAD Sub-TLV. It has the following format: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | AII | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 2: ISIS AII of FAD Sub-TLV format 324 where: 326 Type: TBD1. 328 Length: 4 octets. 330 AII: Administrative Instance Identifier as defined in 331 [I-D.peng-teas-network-slicing]. 333 ISIS AII of FAD Sub-TLV MAY NOT appear more then once in an ISIS FAD 334 Sub-TLV. If it appears more then once, the ISIS FAD Sub-TLV MUST be 335 ignored by the receiver. 337 7.2. OSPF AII of FAD Sub-TLV 339 OSPF AII of FAD Sub-TLV is used to advertise the AII information that 340 is used during the Flex-Algorithm path calculation. It is a Sub-TLV 341 of the OSPF FAD TLV. It has the following format: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | AII | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 3: OSPF AII of FAD Sub-TLV format 353 where: 355 Type: TBD2. 357 Length: 4 octets. 359 AII: Administrative Instance Identifier as defined in 360 [I-D.peng-teas-network-slicing]. 362 OSPF AII of FAD Sub-TLV MAY NOT appear more then once in an OSPF FAD 363 TLV. If it appears more then once, the OSPF FAD TLV MUST be ignored 364 by the receiver. 366 8. IANA Considerations 368 8.1. ISIS IANA Considerations 370 This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs 371 for Flexible Algorithm Definition Sub-TLV" registry: 373 Type: TBD1 375 Description: Administrative Instance Identifier 376 Reference: This document (Section 6.1) 378 8.2. OSPF IANA Considerations 380 This document registers following Sub-TLVs in the "TLVs for Flexible 381 Algorithm Definition TLV" registry: 383 Type: TBD2 385 Description: Administrative Instance Identifier 387 Reference: This document (Section 6.2) 389 9. Security Considerations 391 This specification inherits all security considerations of 392 [I-D.ietf-lsr-flex-algo]. 394 10. Acknowledgements 396 TBD 398 11. Normative References 400 [I-D.ietf-lsr-flex-algo] 401 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 402 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 403 algo-10 (work in progress), August 2020. 405 [I-D.ietf-spring-segment-routing-policy] 406 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 407 P. Mattes, "Segment Routing Policy Architecture", draft- 408 ietf-spring-segment-routing-policy-08 (work in progress), 409 July 2020. 411 [I-D.peng-lsr-flex-algo-l2bundles] 412 Peng, S., Chen, R., and G. Mirsky, "IGP Flexible Algorithm 413 with L2bundles", draft-peng-lsr-flex-algo-l2bundles-02 414 (work in progress), August 2020. 416 [I-D.peng-teas-network-slicing] 417 Peng, S., Chen, R., Mirsky, G., and F. Qin, "Packet 418 Network Slicing using Segment Routing", draft-peng-teas- 419 network-slicing-03 (work in progress), February 2020. 421 [I-D.zch-lsr-isis-network-slicing] 422 Zhu, Y., Chen, R., Peng, S., and F. Qin, "IS-IS Extensions 423 to Support Transport Network Slices using Segment 424 Routing", draft-zch-lsr-isis-network-slicing-06 (work in 425 progress), September 2020. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 433 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 434 RFC 4915, DOI 10.17487/RFC4915, June 2007, 435 . 437 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 438 Topology (MT) Routing in Intermediate System to 439 Intermediate Systems (IS-ISs)", RFC 5120, 440 DOI 10.17487/RFC5120, February 2008, 441 . 443 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 444 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 445 . 447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 449 May 2017, . 451 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 452 Decraene, B., Litkowski, S., and R. Shakir, "Segment 453 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 454 July 2018, . 456 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 457 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 458 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 459 December 2019, . 461 Authors' Addresses 462 Peng Shaofu 463 ZTE Corporation 464 No.68 Zijinghua Road, Yuhuatai District 465 Nanjing 466 China 468 Email: peng.shaofu@zte.com.cn 470 Chen Ran 471 ZTE Corporation 472 No.50 Software Avenue, Yuhuatai District 473 Nanjing 474 China 476 Email: chen.ran@zte.com.cn 478 Greg Mirsky 479 ZTE Corp. 481 Email: gregimirsky@gmail.com