idnits 2.17.1 draft-peng-lsr-flex-algo-opt-slicing-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 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 (November 27, 2019) is 1609 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-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-05 == Outdated reference: A later version (-04) exists of draft-peng-teas-network-slicing-01 Summary: 0 errors (**), 0 flaws (~~), 6 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: May 30, 2020 G. Mirsky 6 ZTE Corp. 7 November 27, 2019 9 IGP Flexible Algorithm Optimazition for Netwrok Slicing 10 draft-peng-lsr-flex-algo-opt-slicing-00 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 May 30, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 6. AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. ISIS AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . 5 62 6.2. OSPF AII of FAD Sub-TLV . . . . . . . . . . . . . . . . . 6 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. ISIS IANA Considerations . . . . . . . . . . . . . . . . 6 65 7.2. OSPF IANA Considerations . . . . . . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] proposes a solution that 74 allows IGPs themselves to compute constraint based paths over the 75 network, and it also specifies a way of using Segment Routing (SR) 76 Prefix-SIDs and SRv6 locators to steer packets along the constraint- 77 based paths. It specifies a set of extensions to ISIS, OSPFv2 and 78 OSPFv3 that enable a router to send TLVs that identify (a) 79 calculation-type, (b) specify a metric-type, and (c )describe a set 80 of constraints on the topology, that are to be used to compute the 81 best paths along the constrained topology. A given combination of 82 calculation-type, metric-type, and constraints is known as an FAD 83 (Flexible Algorithm Definition). 85 [I-D.peng-teas-network-slicing] proposes a solution to extend the 86 control plane of transport network to instantiate the Network Slice 87 Instance (NSI) in transport network. A new identifier, AII, instead 88 of existing TE affinity or other identifiers, is introduced to 89 represent a TN-slice and specify the dedicated resource for the TN- 90 slice. 92 This document extends the FAD of IGP Flex Algorithm to let IGPs 93 compute constraint based paths limited in specific TN-slice. 95 2. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 3. SR Policy Using Slice-based Resources 105 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 106 Policy and steering into an SR Policy. These apply equally to the 107 MPLS and IPv6 (known as SRv6) data plane instantiations of Segment 108 Routing with their respective representations of segments as SR-MPLS 109 SID and SRv6 SID as described in [RFC8402]. The color of SR policy 110 defines a TE purpose, which includes a set of constraints such as 111 bandwidth, delay, TE metric, etc. 113 The overlay service can select underlay SR policy according to a 114 meaningful color value. From the perspective of service, color is 115 the key to get the expected SLA, and it is a global administrative 116 configuration or setting that could be exchangeable between two 117 devices for SR policy on-demand next-hop triggering. The service 118 never concern whether the underlay network has been partitioned as 119 multi-domains, or multi-topologies. That is, color has not semantic 120 local within one domain, or one topology. Instead, any type of 121 resources such as topology, computation, storage could be selected by 122 the color template. In this sense, TN-slices are also high-level 123 resouces that could be selected by color template. A simple way to 124 achieve this is to contain the specific AII information in the color 125 template, to restrict the TE path to the corresponding TN-slice. 127 4. SR Policy Optimaztion with IGP Flex-algo 129 Indeed, FA-id defined in [I-D.ietf-lsr-flex-algo] is a short mapping 130 of SR policy color to optimaze segment stack depth for the IGP area 131 partial of the entire SR policy. The overlay service that want to be 132 carried over a particual SR-FA path must firstly let the SR policy 133 supplier know that requirement. There are two possible ways to map a 134 color to an FA-id. One is explicit mapping configuration within 135 color template, the other is dynamic to replace a long segment list 136 to short FA segment by headend or controller once the creterias 137 contained in the color-template equal to that contained in FAD. 139 [I-D.ietf-lsr-flex-algo] described that Application specific Flex- 140 Algorithm participation advertisements MAY be topology specific or 141 MAY be topology independent, and also emphasize that Segment Routing 142 Flex-Algorithm participation advertisement is topology independent, 143 i.e., when a router advertises participation in an SR-Algorithm, the 144 participation applies to all topologies in which the advertising node 145 participates. Here the topology means Multi-Topology Routing (MTR) 146 described in [RFC5120], [RFC4915], [RFC5340]. [RFC8402] also 147 mentioned that multiple SIDs MAY be allocated to the same prefix so 148 long as the tuple is unique. In fact, 149 this will lead to many forwarding tables, such as table per topology, 150 table per each combined tuple . 152 According to [I-D.peng-teas-network-slicing], we donot use MTR to 153 identify the TN-slice and partition the virtual topology for the TN- 154 slice. Instead, a slice-based identifier AII is introduced to 155 represent a TN-slice, and the first feature of AII is a TE criteria 156 for TE service just like AG/EAG. In order to make the contents of 157 the color template and mapping FAD consistent, AII is also necessary 158 put into FAD. 160 Although the network operator may change the AII information within 161 the FAD for the specific FA-id, there is only one forwarding table 162 with constant table ID, i.e., FA-id. Note that there are also 163 independent forwarding tables per AII, but not those per tuple . That is, FA-id has not semantic local within AII, as the 165 same as color. 167 5. IGP Flex-algo Enhancement with AII 169 FAD that contains AII information will enhance the capability of 170 Flex-algo to support network slicing. For example, Loop Free 171 Alternate (LFA) paths for a given Flex-Algorithm can include Prefix- 172 SIDs advertised specifically for the given algorithm, and especially 173 Adjacency-SIDs for the specific AII. When different FA planes share 174 the same link resouce, Adjacency-SID per AII (according to 175 [I-D.peng-teas-network-slicing]) can distinguish the flow of 176 different slices well and provide different treatment. 178 The following figure shows an example of Flex-algo enhancement with 179 AII. 181 [S1]--------[D]--------[S2] 182 | | | 183 | | | 184 | | | 185 [A]---------[B]--------[C] 187 Figure 1: Flex-algo Enhancement with AII 189 Suppose that node S1, A, B, D and their inter-connected links belongs 190 to FA-id 128 plane as well as AII-1, and S2, B, C, D and their inter- 191 connected links belongs to FA-id 129 plane as well as AII-2. The IGP 192 metric of link B-D is 100, and all other links have IGP metric 1. In 193 FA-id 128 plane, from S1 to destination D, the primary path is S1-D, 194 and the TI-LFA backup path is segment list {node(B), adjacency(B-D)}. 195 Similarly, In FA-id 129 plane, from S2 to destination D, the primary 196 path is S2-D, and the TI-LFA backup path is segment list {node(B), 197 adjacency(B-D)}. With the help of AII parameter contained in the FAD, 198 the above TI-LFA path of FA-id 128 plane will be translated to {node- 199 SID(B)@FA-id128, adjacency-SID(B-D)@AII-1}, and TI-LFA path of FA-id 200 129 plane will be translate to {node-SID(B)@FA-id129, adjacency- 201 SID(B-D)@AII-2}. So that node B can distinguish the flow of FA-id 128 202 and FA-id 129 with different treatment (e.g., QoS) and send to the 203 same outgoing link B-D. 205 For inter-domain case, different domain can config different FA-id 206 independently, but they can contain the same AII to construct an E2E 207 slice-based SR policy. IGP flex-algo is responsible for creating 208 constraint based paths within the domain according to FAD including 209 AII parameter, and BGP-LU or SDN controller is responsible for 210 selecting inter-domain links according to color template including 211 AII parameter. AII is easy to address the requirement of E2E Slicing 212 view. 214 6. AII of FAD Sub-TLV 216 6.1. ISIS AII of FAD Sub-TLV 218 ISIS AII of FAD Sub-TLV is used to advertise the AII information that 219 is used during the Flex-Algorithm path calculation. It is a Sub-TLV 220 of the ISIS FAD Sub-TLV. It has the following format: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | AII | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2: ISIS AII of FAD Sub-TLV format 232 where: 234 Type: TBD1. 236 Length: 4 octets. 238 AII: Administrative Instance Identifier as defined in 239 [I-D.peng-teas-network-slicing]. 241 ISIS AII of FAD Sub-TLV MAY NOT appear more then once in an ISIS FAD 242 Sub-TLV. If it appears more then once, the ISIS FAD Sub-TLV MUST be 243 ignored by the receiver. 245 6.2. OSPF AII of FAD Sub-TLV 247 OSPF AII of FAD Sub-TLV is used to advertise the AII information that 248 is used during the Flex-Algorithm path calculation. It is a Sub-TLV 249 of the OSPF FAD TLV. It has the following format: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | AII | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 3: OSPF AII of FAD Sub-TLV format 261 where: 263 Type: TBD2. 265 Length: 4 octets. 267 AII: Administrative Instance Identifier as defined in 268 [I-D.peng-teas-network-slicing]. 270 OSPF AII of FAD Sub-TLV MAY NOT appear more then once in an OSPF FAD 271 TLV. If it appears more then once, the OSPF FAD TLV MUST be ignored 272 by the receiver. 274 7. IANA Considerations 276 7.1. ISIS IANA Considerations 278 This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs 279 for Flexible Algorithm Definition Sub-TLV" registry: 281 Type: TBD1 282 Description: Administrative Instance Identifier 284 Reference: This document (Section 6.1) 286 7.2. OSPF IANA Considerations 288 This document registers following Sub-TLVs in the "TLVs for Flexible 289 Algorithm Definition TLV" registry: 291 Type: TBD2 293 Description: Administrative Instance Identifier 295 Reference: This document (Section 6.2) 297 8. Security Considerations 299 This specification inherits all security considerations of 300 [I-D.ietf-lsr-flex-algo]. 302 9. Acknowledgements 304 TBD 306 10. Normative References 308 [I-D.ietf-lsr-flex-algo] 309 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 310 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 311 algo-05 (work in progress), November 2019. 313 [I-D.ietf-spring-segment-routing-policy] 314 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 315 P. Mattes, "Segment Routing Policy Architecture", draft- 316 ietf-spring-segment-routing-policy-05 (work in progress), 317 November 2019. 319 [I-D.peng-teas-network-slicing] 320 Peng, S., Chen, R., Mirsky, G., and F. Qin, "Packet 321 Network Slicing using Segment Routing", draft-peng-teas- 322 network-slicing-01 (work in progress), November 2019. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 330 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 331 RFC 4915, DOI 10.17487/RFC4915, June 2007, 332 . 334 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 335 Topology (MT) Routing in Intermediate System to 336 Intermediate Systems (IS-ISs)", RFC 5120, 337 DOI 10.17487/RFC5120, February 2008, 338 . 340 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 341 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 349 Decraene, B., Litkowski, S., and R. Shakir, "Segment 350 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 351 July 2018, . 353 Authors' Addresses 355 Peng Shaofu 356 ZTE Corporation 357 No.68 Zijinghua Road, Yuhuatai District 358 Nanjing 359 China 361 Email: peng.shaofu@zte.com.cn 363 Chen Ran 364 ZTE Corporation 365 No.50 Software Avenue, Yuhuatai District 366 Nanjing 367 China 369 Email: chen.ran@zte.com.cn 371 Greg Mirsky 372 ZTE Corp. 374 Email: gregimirsky@gmail.com