idnits 2.17.1 draft-peng-lsr-flex-algo-opt-slicing-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 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 (March 9, 2020) is 1508 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-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-05) exists of draft-peng-lsr-flex-algo-l2bundles-00 == Outdated reference: A later version (-04) exists of draft-peng-teas-network-slicing-03 == Outdated reference: A later version (-06) exists of draft-zch-lsr-isis-network-slicing-03 Summary: 0 errors (**), 0 flaws (~~), 8 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: September 10, 2020 G. Mirsky 6 ZTE Corp. 7 March 9, 2020 9 IGP Flexible Algorithm Optimazition for Netwrok Slicing 10 draft-peng-lsr-flex-algo-opt-slicing-01 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 satisfy network 19 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 September 10, 2020. 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 . . . . . . . . . . . . . 4 60 5.1. Enhancement for TI-LFA . . . . . . . . . . . . . . . . . 4 61 5.2. Enhancement for Inter-domain . . . . . . . . . . . . . . 5 62 5.3. Enhancement for L2bundles . . . . . . . . . . . . . . . . 5 63 6. AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. ISIS AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . 6 65 6.2. OSPF AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. ISIS IANA Considerations . . . . . . . . . . . . . . . . 7 68 7.2. OSPF IANA Considerations . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] proposes a solution that 77 allows IGPs themselves to compute constraint based paths over the 78 network, and it also specifies a way of using Segment Routing (SR) 79 Prefix-SIDs and SRv6 locators to steer packets along the constraint- 80 based paths. It specifies a set of extensions to ISIS, OSPFv2 and 81 OSPFv3 that enable a router to send TLVs that identify (a) 82 calculation-type, (b) specify a metric-type, and (c )describe a set 83 of constraints on the topology, that are to be used to compute the 84 best paths along the constrained topology. A given combination of 85 calculation-type, metric-type, and constraints is known as an FAD 86 (Flexible Algorithm Definition). 88 [I-D.peng-teas-network-slicing] proposes a solution to extend the 89 control plane of transport network to instantiate the Network Slice 90 Instance (NSI) in transport network. A new identifier, AII, instead 91 of existing TE affinity or other identifiers, is introduced to 92 represent a TN-slice and specify the dedicated resource for the TN- 93 slice. 95 This document extends the FAD of IGP Flex Algorithm to let IGPs 96 compute constraint based paths limited in specific TN-slice. 98 2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 3. SR Policy Using Slice-based Resources 108 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 109 Policy and steering into an SR Policy. These apply equally to the 110 MPLS and IPv6 (known as SRv6) data plane instantiations of Segment 111 Routing with their respective representations of segments as SR-MPLS 112 SID and SRv6 SID as described in [RFC8402]. The color of SR policy 113 defines a TE purpose, which includes a set of constraints such as 114 bandwidth, delay, TE metric, etc. 116 The overlay service can select underlay SR policy according to a 117 meaningful color value. From the perspective of service, color is 118 the key to get the expected SLA, and it is a global administrative 119 configuration or setting that could be exchangeable between two 120 devices for SR policy on-demand next-hop triggering. The service 121 never concern whether the underlay network has been partitioned as 122 multi-domains, or multi-topologies. That is, color has not semantic 123 local within one domain, or one topology. Instead, any type of 124 resources such as topology, computation, storage could be selected by 125 the color template. In this sense, TN-slices are also high-level 126 resouces that could be selected by color template. A simple way to 127 achieve this is to contain the specific AII information in the color 128 template, to restrict the TE path to the corresponding TN-slice. 130 4. SR Policy Optimaztion with IGP Flex-algo 132 Indeed, FA-id defined in [I-D.ietf-lsr-flex-algo] is a short mapping 133 of SR policy color to optimaze segment stack depth for the IGP area 134 partial of the entire SR policy. The overlay service that want to be 135 carried over a particual SR-FA path must firstly let the SR policy 136 supplier know that requirement. There are two possible ways to map a 137 color to an FA-id. One is explicit mapping configuration within 138 color template, the other is dynamic to replace a long segment list 139 to short FA segment by headend or controller once the creterias 140 contained in the color-template equal to that contained in FAD. 142 [I-D.ietf-lsr-flex-algo] described that Application specific Flex- 143 Algorithm participation advertisements MAY be topology specific or 144 MAY be topology independent, and also emphasize that Segment Routing 145 Flex-Algorithm participation advertisement is topology independent, 146 i.e., when a router advertises participation in an SR-Algorithm, the 147 participation applies to all topologies in which the advertising node 148 participates. Here the topology means Multi-Topology Routing (MTR) 149 described in [RFC5120], [RFC4915], [RFC5340]. [RFC8402] also 150 mentioned that multiple SIDs MAY be allocated to the same prefix so 151 long as the tuple is unique. In fact, 152 this will lead to many forwarding tables, such as table per topology, 153 table per each combined tuple . 155 According to [I-D.peng-teas-network-slicing], we donot use MTR to 156 identify the TN-slice and partition the virtual topology for the TN- 157 slice. Instead, a slice-based identifier AII is introduced to 158 represent a TN-slice, and the first feature of AII is a TE criteria 159 for TE service just like AG/EAG. In order to make the contents of 160 the color template and mapping FAD consistent, AII is also necessary 161 put into FAD. 163 Although the network operator may change the AII information within 164 the FAD for the specific FA-id, there is only one forwarding table 165 with constant table ID, i.e., FA-id. Note that there are also 166 independent forwarding tables per AII, but not those per tuple . That is, FA-id has not semantic local within AII, as the 168 same as color. 170 5. IGP Flex-algo Enhancement with AII 172 FAD that contains AII information will enhance the capability of 173 Flex-algo to support network slicing. 175 5.1. Enhancement for TI-LFA 177 Loop Free Alternate (LFA) paths for a given Flex-Algorithm can 178 include Prefix-SIDs advertised specifically for the given algorithm, 179 and especially Adjacency-SIDs for the specific AII. When different 180 FA planes share the same link resouce, Adjacency-SID per AII 181 (according to [I-D.peng-teas-network-slicing]) can distinguish the 182 flow of different slices well and provide different treatment. 184 The following figure shows an example of Flex-algo enhancement with 185 AII. 187 [S1]--------[D]--------[S2] 188 | | | 189 | | | 190 | | | 191 [A]---------[B]--------[C] 193 Figure 1: Flex-algo LFA Enhancement with AII 195 Suppose that node S1, A, B, D and their inter-connected links belongs 196 to FA-id 128 plane as well as AII-1, and S2, B, C, D and their inter- 197 connected links belongs to FA-id 129 plane as well as AII-2. The IGP 198 metric of link B-D is 100, and all other links have IGP metric 1. In 199 FA-id 128 plane, from S1 to destination D, the primary path is S1-D, 200 and the TI-LFA backup path is segment list {node(B), adjacency(B-D)}. 201 Similarly, In FA-id 129 plane, from S2 to destination D, the primary 202 path is S2-D, and the TI-LFA backup path is segment list {node(B), 203 adjacency(B-D)}. With the help of AII parameter contained in the FAD, 204 the above TI-LFA path of FA-id 128 plane will be translated to {node- 205 SID(B)@FA-id128, adjacency-SID(B-D)@AII-1}, and TI-LFA path of FA-id 206 129 plane will be translate to {node-SID(B)@FA-id129, adjacency- 207 SID(B-D)@AII-2}. So that node B can distinguish the flow of FA-id 128 208 and FA-id 129 with different treatment (e.g., QoS) and send to the 209 same outgoing link B-D. 211 5.2. Enhancement for Inter-domain 213 For inter-domain case, different domain can config different FA-id 214 independently, but they can contain the same AII to construct an E2E 215 slice-based SR policy. IGP flex-algo is responsible for creating 216 constraint based paths within the domain according to FAD including 217 AII parameter, and BGP-LU or SDN controller is responsible for 218 selecting inter-domain links according to color template including 219 AII parameter. AII is easy to address the requirement of E2E Slicing 220 view. 222 5.3. Enhancement for L2bundles 224 [RFC8668] inroduced L2 Bundle Member Attributes sub-TLV to be 225 advertised within ISIS TLV-22/23/141/222/223. It may define an 226 attribute common to all of the bundle members listed and an attribute 227 individual to each L2 Bundle Member. [RFC8668] mainly defined 228 Adjacency-SID for each L2 Bundle Member, that is very useful to 229 isolate flows among different slices. A typical deployment of hard 230 slicing is that different L2 Bundle Member, e.g, Flex-E channel, 231 belongs to different TN-slice, so a specific Adjacency-SID for a 232 specific L2 Bundle Member will steer the packets to that member. 234 However, the link resource of an FA plane is selected according to 235 the TE affinity attribute of all L3 links joining to the IGP instance 236 and the INCLUDE/EXCLUDE rules contained in the FAD. If we want to 237 let different L2 Bundle Member belongs to different FA plane, it msut 238 determine the TE affinity of each L2 Bundle Member. There could have 239 two methods: 241 o [I-D.zch-lsr-isis-network-slicing] extends ISIS protocol to carry 242 AII (TN-slice ID) information for each L2 Bundle Member within L2 243 Bundle Member Attributes sub-TLV defined in [RFC8668]. Even 244 though the same L3 parrent link can be joined to multiple FA 245 planes according to TE affinity INCLUDE/EXCLUDE rules, it is easy 246 for each FA plane to exactly use the specific L2 Bundle Member 247 according to the AII information contained in FAD. 249 o It is also possible to directly define AG/EGA per L2 Bundle Member 250 for Flex-algo application. [I-D.peng-lsr-flex-algo-l2bundles] 251 described how to create Flex-algo plane in the case of L2bundles 252 scenario, by explicit AG/EGA affinity configuration for each L2 253 Bundle Member. This method is similar with the above definition 254 of AII per L2 Bundle Member, both them can distinguish traffic of 255 different hard slice. 257 6. AII of FAD Sub-TLV 259 6.1. ISIS AII of FAD Sub-TLV 261 ISIS AII of FAD Sub-TLV is used to advertise the AII information that 262 is used during the Flex-Algorithm path calculation. It is a Sub-TLV 263 of the ISIS FAD Sub-TLV. It 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 | AII | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 2: ISIS AII of FAD Sub-TLV format 275 where: 277 Type: TBD1. 279 Length: 4 octets. 281 AII: Administrative Instance Identifier as defined in 282 [I-D.peng-teas-network-slicing]. 284 ISIS AII of FAD Sub-TLV MAY NOT appear more then once in an ISIS FAD 285 Sub-TLV. If it appears more then once, the ISIS FAD Sub-TLV MUST be 286 ignored by the receiver. 288 6.2. OSPF AII of FAD Sub-TLV 290 OSPF AII of FAD Sub-TLV is used to advertise the AII information that 291 is used during the Flex-Algorithm path calculation. It is a Sub-TLV 292 of the OSPF FAD TLV. It has the following format: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | AII | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 3: OSPF AII of FAD Sub-TLV format 304 where: 306 Type: TBD2. 308 Length: 4 octets. 310 AII: Administrative Instance Identifier as defined in 311 [I-D.peng-teas-network-slicing]. 313 OSPF AII of FAD Sub-TLV MAY NOT appear more then once in an OSPF FAD 314 TLV. If it appears more then once, the OSPF FAD TLV MUST be ignored 315 by the receiver. 317 7. IANA Considerations 319 7.1. ISIS IANA Considerations 321 This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs 322 for Flexible Algorithm Definition Sub-TLV" registry: 324 Type: TBD1 326 Description: Administrative Instance Identifier 327 Reference: This document (Section 6.1) 329 7.2. OSPF IANA Considerations 331 This document registers following Sub-TLVs in the "TLVs for Flexible 332 Algorithm Definition TLV" registry: 334 Type: TBD2 336 Description: Administrative Instance Identifier 338 Reference: This document (Section 6.2) 340 8. Security Considerations 342 This specification inherits all security considerations of 343 [I-D.ietf-lsr-flex-algo]. 345 9. Acknowledgements 347 TBD 349 10. Normative References 351 [I-D.ietf-lsr-flex-algo] 352 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 353 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 354 algo-06 (work in progress), February 2020. 356 [I-D.ietf-spring-segment-routing-policy] 357 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 358 P. Mattes, "Segment Routing Policy Architecture", draft- 359 ietf-spring-segment-routing-policy-06 (work in progress), 360 December 2019. 362 [I-D.peng-lsr-flex-algo-l2bundles] 363 Peng, S., Chen, R., and G. Mirsky, "IGP Flexible Algorithm 364 with L2bundles", draft-peng-lsr-flex-algo-l2bundles-00 365 (work in progress), December 2019. 367 [I-D.peng-teas-network-slicing] 368 Peng, S., Chen, R., Mirsky, G., and F. Qin, "Packet 369 Network Slicing using Segment Routing", draft-peng-teas- 370 network-slicing-03 (work in progress), February 2020. 372 [I-D.zch-lsr-isis-network-slicing] 373 Zhu, Y., Chen, R., Peng, S., and F. Qin, "IS-IS Extensions 374 to Support Packet Network Slicing using Segment Routing", 375 draft-zch-lsr-isis-network-slicing-03 (work in progress), 376 December 2019. 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, 380 DOI 10.17487/RFC2119, March 1997, 381 . 383 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 384 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 385 RFC 4915, DOI 10.17487/RFC4915, June 2007, 386 . 388 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 389 Topology (MT) Routing in Intermediate System to 390 Intermediate Systems (IS-ISs)", RFC 5120, 391 DOI 10.17487/RFC5120, February 2008, 392 . 394 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 395 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 396 . 398 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 399 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 400 May 2017, . 402 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 403 Decraene, B., Litkowski, S., and R. Shakir, "Segment 404 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 405 July 2018, . 407 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 408 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 409 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 410 December 2019, . 412 Authors' Addresses 413 Peng Shaofu 414 ZTE Corporation 415 No.68 Zijinghua Road, Yuhuatai District 416 Nanjing 417 China 419 Email: peng.shaofu@zte.com.cn 421 Chen Ran 422 ZTE Corporation 423 No.50 Software Avenue, Yuhuatai District 424 Nanjing 425 China 427 Email: chen.ran@zte.com.cn 429 Greg Mirsky 430 ZTE Corp. 432 Email: gregimirsky@gmail.com