idnits 2.17.1 draft-zzhang-teas-network-slicing-with-flex-te-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8402]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1373 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) == Missing Reference: 'I-D.zzhang-idr-bgp-rt-constrain-extension' is mentioned on line 360, but not defined == Unused Reference: 'I-D.zzhang-idr-bgp-rt-constrains-extension' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'I-D.zzhang-idr-bitmask-route-target' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'I-D.dong-network-slicing-problem-statement' is defined on line 416, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-07 == Outdated reference: A later version (-03) exists of draft-zzhang-idr-bgp-rt-constrains-extension-00 == Outdated reference: A later version (-01) exists of draft-zzhang-idr-bitmask-route-target-00 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-07) exists of draft-drake-bess-enhanced-vpn-03 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Z. Zhang 3 Internet-Draft S. Hegde 4 Intended status: Standards Track Juniper Networks 5 Expires: January 14, 2021 A. Gulko 6 Refinitiv 7 July 13, 2020 9 Network Slicing with Flexible Traffic Engineering 10 draft-zzhang-teas-network-slicing-with-flex-te-00 12 Abstract 14 This document specifies procedures and signaling enhancements to 15 Flexible Algoirthm to ease provisoning and to scale it better via 16 Flexible Traffic Engineering, which is an integration of Flexible 17 Algorithm and Segment Routing [RFC8402] Traffic Engineering (SR-TE). 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" in this document are to be interpreted as described in BCP 24 14 [RFC2119] [RFC8174] when, and only when, they appear in all 25 capitals, as shown here. 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 January 14, 2021. 44 Copyright Notice 46 Copyright (c) 2020 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. FlexAlgo Background . . . . . . . . . . . . . . . . . . . 3 63 1.2. Central Provisioning and Signaling of FlexAlgo . . . . . 4 64 1.3. Flexible Traffic Engineering (FlexTE) and Targeted 65 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.4. Traffic Isolation and FlexAlgo/FlexTE . . . . . . . . . . 5 67 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1. Southbound BGP-LS Encoding of FAD . . . . . . . . . . . . 6 69 2.2. Southbound BGP-LS Encoding of Link Administrative Group 70 Information . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.3. OSPF/ISIS Encoding of Link Administrative Group 72 Information for Cetralized Advertisement . . . . . . . . 7 73 2.4. FlexAlgo and Link AG Signaling from Controllers . . . . . 8 74 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 6.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 [dong-network-slicing-problem-statement] defines Network Slicing 85 Problem Statement for IP/MPLS networks. While Virtual Private 86 Networks (VPNs) have been widely deployed to provide many different 87 virtual networks on the same physical operator network, and can be 88 reused to provide network slicing service to applications, currently 89 those VPNs share the same underlay operator network without any 90 separation and isolation. 92 Multi-Topology Routing (MTR) [RFC4915] [RFC5120] provides a mechanism 93 to have a set of independent IP topologies referred to as Multi- 94 Topologies (MTs) over the same underlay network. It can be used to 95 provide separation and isolation required by network slicing, though 96 MTR has not been widely deployed over the years, except limited usage 97 of maintaining separate IGP routing domains for isolated multicast 98 islands within the backbone. 100 Some reasons for MTR's lack of success are listed below: 102 1. Lack of strong demand for mapping traffic to different MTs 104 2. Lack of good mechanism for mapping traffic to different MTs 106 3. Lack of operating tools to ease provisioning and monitoring 108 In 5G era, 1) is no longer the case and 3) needs to be addressed 109 given the network slicing requirements. 2) is addressed by SR and 110 Flexible Algorithm (FlexAlgo) [ietf-lsr-flex-algo]. This document 111 specifies signaling enhancements to FlexAlgo to ease provisoning and 112 to scale it better via Flexible Traffic Engineering (FlexTE), which 113 is an integration of FlexAlgo and Segment Routing [RFC8402] Traffic 114 Engineering (SR-TE). 116 1.1. FlexAlgo Background 118 FlexAlgo can be viewed as a more flexible and light-weighted 119 mechanism of MTR. A Flexible Algorithm is defined as a tuple. 121 The "Included/excluded Administrative Group" defines the 122 (sub-)topology used for the algorithm. While there are different 123 metric types to be used, there are no per-algorithm metric values 124 advertised for links. 126 Routers are configured to use certain algoirthms for its SPF 127 calculations. Definitions for the algorithms are locally configured 128 and/or learnt through signaling. 130 The Administrative Groups (AG) of a link, which are often referred to 131 as link colors, are advertised in a 32-bit AG BitMask as sepcified in 132 [RFC3630] [RFC5305] or an arbitrary length EAG BitMask as specified 133 in [RFC7308]. The advertisements are originated from the router 134 owning the link based on local provisioning. 136 While not a mandatroy part of FlexAlgo, Segment Routing can be 137 integrated with FlexAlgo seamlessly to map traffic to different 138 algorithms: prefix SIDs can optionally be associated with algorithms, 139 so that a prefix can be reached via different SIDs or SID lists, 140 following different paths. 142 1.2. Central Provisioning and Signaling of FlexAlgo 144 More and more operators use controllers for centralized 145 orchestration, provisioning and signaling. In fact, even before the 146 controllers were used, the network planning was centralized, albeit 147 done manually, and then configuration information resulting from 148 centralized planning was entered into individual routers via out of 149 band means. 151 The centralized model can be applied to FlexAlgo very well - instead 152 of provisioning FAD and link AGs on individual routers after 153 centralized planning, the provisioning is be done centrally on the 154 controllers and then constraints and link AG information are signaled 155 to routers. 157 Given that it is very common for controllers to learn network 158 information via northbound BGP-LS [RFC7752], this document uses 159 southbound BGP-LS to distribute FAD and link AG information from 160 controllers to BGP-LS speakers. This can also take advantages of 161 inherent BGP mechanisms for optimized large scale state distribution. 162 If not all routers but only IGP border routers run BGP-LS, the border 163 routers will then flood received information via IGP. 165 1.3. Flexible Traffic Engineering (FlexTE) and Targeted Signaling 167 With current FlexAlgo mechanisms, Flexible Algorithm Definitions 168 (FADs) and link AG information are flooded throughout an IGP area and 169 every router will do an SPF calculation for each algorithm. This may 170 work for a few algorithms but it will not scale for larger number of 171 alorithms that are necessary for large number of slices in some 5G 172 scenarios. 174 To address the scaling problem, the above flooded information and SPF 175 caculation may be restricted to network edge only. The idea is first 176 introduced in [I-D.drake-bess-enhanced-vpn] but adapted to FlexAlgo 177 in this document. 179 With this scheme, the internal routers don't have per-algorithm 180 information and do not do per-algorithm based SPF or per-algorithm 181 prefix-SID based forwarding. The edge routers use SR-TE Adjacency 182 SID-lists to explicitly steer traffic through the network. This is 183 referred to as Flexible Traffic Engineering (FlexTE), an integraion 184 of Flexible Algorithm and SR Traffic Engineering. 186 Specifically, with BGP Route Target [RFC4364] and Route Target 187 Constrains [RFC4684] mechanisms, the FADs and link AG information are 188 only propagated to and imported by edge routers that need that 189 information. For example, if a network slice is presented to 190 application as a VPN and instantiated in the underlay with a Flexible 191 Algorithm that utilizes only "red" links, then that specific FAD and 192 "red" link AG information are advertised to and imported by only PEs 193 for that VPN (if the same algorithm is used by many VPNs then all PEs 194 of those VPNs will import the relevant information). 196 For better scalability, the link AG information is encoded in a new 197 type of Route Target (RT) used for the control of route propagation 198 and importation, as detailed in Section 2.2 and [I-D.zzhang-idr- 199 bitmask-route-target]. 201 Because a router may not be able to push too deep a label stack, per- 202 algorithm Binding SIDs may have to be used. For example, if there 203 are 10 hops from PE1 to PE2 while the maximum labels that PE1 can 204 push is 5, then PE1 has to use a label stack that specifies the 205 explicit hop-by-hop path (calculated by an algorithm) to an 206 intermediate router P1 and a binding SID advertised by P1 for PE2. 207 For P1 to calculate the per-algorithm explicit path to PE2, it also 208 needs to know the information for that algorithm, and it can do so 209 following the same way as how PE1 learns the information. 211 1.4. Traffic Isolation and FlexAlgo/FlexTE 213 FlexAlgo as described in [I-D.ietf-lsr-flex-algo] seprates the 214 routing domain into different planes. The primary and backup paths 215 are computed based on the topology that corresponds to the plane. 216 FlexAlgo provides strict isolation of the data traffic between the 217 different planes. Notice that FlexAlgo is suitable for slices that 218 need complete isolation. Packet transportnetworks are expected to 219 have a limited number of such isolated routing planes. 221 With FlexTE, traffic isolation is achieved via SR-TE Adjacency SID 222 lists, but during local Fast ReRoute (FRR) traffic may flow through 223 paths that don't satisfy constraints. If the SR-TE SID list is too 224 long, Node SIDs may be used but the traffic isolation is not possible 225 on the path between node SIDs, unless some internal routers also get 226 targeted signaling, behave as edge routers, and advertise per- 227 algorithm Node/Binding SIDs (targeted at the edge routers and those 228 selected internal routers). Therefore, FlexTE is more suitable for 229 soft slicing where traffic isolation is not critical in certain 230 situations. 232 With 5G, network slicing requires high number of slices though they 233 may not necessarily require routing plane isolation but they may need 234 to satisfy certain constraints and have guaranteed Quality Of 235 Service, and FlexTE as a flexible soft slicing solution allows for 236 slice creation inside specific isolated planes or in a generic plane. 238 The QOS guarantees for the slices are outside the scope of this 239 document. 241 2. Specification 243 BGP-LS [RFC7752] is for "North-Bound Distribution of Link-State and 244 Traffic Engineering (TE) Information Using BGP". This document 245 extends it for south-bound distribution of FlexAlgo/TE constraint 246 related information, and specifies relavent procedures for FlexAlgo 247 based on centralized, targeted signaling. 249 2.1. Southbound BGP-LS Encoding of FAD 251 Currently BGP-LS uses the following NLRI format with AFI 16388 and 252 SAFI 71/72: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | NLRI Type | Total NLRI Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 + Route Distinguisher (only with SAFI 72) + 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 // Link-State NLRI (variable) // 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 A new NLRI type TBD1 is added to advertise FAD. For simplicity, the 269 variale Link-State NLRI field has the exactly same TLV format of ISIS 270 FAD Sub-TLV as specified in [I-D.ietf-lsr-flex-algo], including the 271 Type number and Sub-TLVs. 273 +------+-------------------------------+ 274 | Type | NLRI Type | 275 +------+-------------------------------+ 276 | 1 | Node NLRI | 277 | 2 | Link NLRI | 278 | 3 | IPv4 Topology Prefix NLRI | 279 | 4 | IPv6 Topology Prefix NLRI | 280 | TBD1 | Flexible Algorithm Definition | 281 +------+-------------------------------+ 283 2.2. Southbound BGP-LS Encoding of Link Administrative Group 284 Information 286 Currently, BGP-LS encodes link Administrative Group information as a 287 Type 1088 Administrative Group TLV in BGP-LS attribute attached to 288 Link NLRIs that are propagated northbound from routers to 289 controllers. For the southbound signaling of Administrative Group 290 information from controllers, for the purpose of targeted propagation 291 and importation, the Administrative Group information are encoded in 292 a new Bitmask Route Target as specified in [I-D.zzhang-idr-bitmask- 293 route-target]. The Administrative Group TLV is omitted from the BGP- 294 LS Attribute for the link because the information is already encoded 295 in the BitMask RT. 297 Specifically, the EAG BitMask is encoded into the Bitmask field of a 298 Bitmask RT that is attached to the Link NLRI for the link. The 299 Global Administrator (GA) Type, GA Length, and Local Administrator 300 fields are set according to the operator's need to provide a context. 302 To distinguish from Link NLRIs signaled northbound by routers, the 303 Protocol-ID of the Link NLRI is set to BGP (to be assigned by IANA). 305 2.3. OSPF/ISIS Encoding of Link Administrative Group Information for 306 Cetralized Advertisement 308 When centralized provisioning and signaling is not used, an OSPF 309 router advertises its local links' attributes in OSPFv2 Extended Link 310 Opaque LSAs. The LSA includes OSPFv2 Extended Link TLVs, one for 311 each link, which in turn includes sub-TLVs for specific link 312 attributes. 314 The same OSPFv2 Extended Link TLVs can be used for ABRs to flood link 315 attributes that are centrally provisioned on and signaled from 316 controllers, but they MUST additionally carry a new sub-TLV to 317 indidate the routers that host the links, because these Extended Link 318 TLVs are in the Extended Link Opaque LSAs originated by the ABRs not 319 those originated by the routers hosting the links. The sub-TLV is 320 called Hosting Router sub-TLV, with a new TBD2 type and a 4-octet 321 value for the Rouer ID of the router hosting the link. 323 For OSPFv3, a router advertises its local links' TE attributes in 324 Intra-Area-TE LSAs, which contains Link TLVs with link attribute sub- 325 TLVs. Similarly to OSPFv2, when ABRs flood the link attributes that 326 are centrally provisioned on and signaled from controllers, the Link 327 TLVs MUST carry the Hosting Router sub-TLV. 329 For ISIS, the Link Administrative Group information is signaled as 330 sub-TLVs in Extended IS Reachability TLV [RFC5305]. Similarlly, when 331 ABRs flood the link attributes that are centrally provisioned on and 332 signaled from controllers, the Extended IS Reachability TLV MUST 333 carry a new Hosting System sub-TLV. The sub-TLV has a new type TBD3 334 and a 7-octet value for system ID and pseudonode number. 336 When a router receives a OSPFv2/OSPFv3 Link TLV with Hosting Router 337 sub-TLV or an ISIS Extended IS Reachability TLV with Hosting System 338 sub-TLV, it MUST associate the link with the advertised hosting 339 router/system, not with the originator of the OSPF LSA or ISIS LSP. 341 2.4. FlexAlgo and Link AG Signaling from Controllers 343 With centralized provisioning and signaling, a controller signals 344 Link AG information using BGP-LS Link NLRI with a BitMask RT 345 attached, as specified in Section 2.2. 347 The controller signals FADs used in the domain using the BGP-LS NLRI 348 type TBD1. The updates carry a Bitmask RT with the bits set for the 349 AGs that the FADs care about. 351 Routers that need to learn the information MUST have a BitMask RT 352 locally configured, with the bits set for the AGs that they care 353 about, so that they will import corresponding NLRIs. In case of 354 FlexTE, only edge routers and some internal routers will have the 355 BitMask RT locally configured. Otherwise, all BGP-LS routers are 356 configured with a BitMask RT to import all FAD and Link NLRIs. 358 To optimize the propagation of south-bound BGP-LS NLRIs, Route Target 359 Constrain [RFC4684] mechanisms SHOULD be used for Bitmask RT as well, 360 as specified in [I-D.zzhang-idr-bgp-rt-constrain-extension]. 362 3. Security Considerations 364 To be added. 366 4. IANA Considerations 368 To be added. 370 5. Acknowledgements 372 The authors thank Jeff Haas, Srihari Sangli and Colby Barth for their 373 comments and suggestions. 375 6. References 377 6.1. Normative References 379 [I-D.ietf-lsr-flex-algo] 380 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 381 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 382 algo-07 (work in progress), April 2020. 384 [I-D.zzhang-idr-bgp-rt-constrains-extension] 385 Zhang, Z. and J. Haas, "Route Target Constrain Extension", 386 draft-zzhang-idr-bgp-rt-constrains-extension-00 (work in 387 progress), July 2020. 389 [I-D.zzhang-idr-bitmask-route-target] 390 Zhang, Z., Ramachandra, S., and J. Haas, "Bitmask Route 391 Target", draft-zzhang-idr-bitmask-route-target-00 (work in 392 progress), July 2020. 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 400 S. Ray, "North-Bound Distribution of Link-State and 401 Traffic Engineering (TE) Information Using BGP", RFC 7752, 402 DOI 10.17487/RFC7752, March 2016, 403 . 405 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 406 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 407 May 2017, . 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 6.2. Informative References 416 [I-D.dong-network-slicing-problem-statement] 417 Dong, J. and S. Bryant, "Problem Statement of Network 418 Slicing in IP/MPLS Networks", draft-dong-network-slicing- 419 problem-statement-00 (work in progress), October 2016. 421 [I-D.drake-bess-enhanced-vpn] 422 Drake, J., Farrel, A., Jalil, L., and A. Lingala, "BGP-LS 423 Filters : A Framework for Network Slicing and Enhanced 424 VPNs", draft-drake-bess-enhanced-vpn-03 (work in 425 progress), May 2020. 427 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 428 (TE) Extensions to OSPF Version 2", RFC 3630, 429 DOI 10.17487/RFC3630, September 2003, 430 . 432 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 433 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 434 2006, . 436 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 437 R., Patel, K., and J. Guichard, "Constrained Route 438 Distribution for Border Gateway Protocol/MultiProtocol 439 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 440 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 441 November 2006, . 443 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 444 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 445 RFC 4915, DOI 10.17487/RFC4915, June 2007, 446 . 448 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 449 Topology (MT) Routing in Intermediate System to 450 Intermediate Systems (IS-ISs)", RFC 5120, 451 DOI 10.17487/RFC5120, February 2008, 452 . 454 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 455 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 456 2008, . 458 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 459 Traffic Engineering (MPLS-TE)", RFC 7308, 460 DOI 10.17487/RFC7308, July 2014, 461 . 463 Authors' Addresses 465 Zhaohui Zhang 466 Juniper Networks 468 EMail: zzhang@juniper.net 469 Shraddha Hegde 470 Juniper Networks 472 EMail: shraddha@juniper.net 474 Arkadiy Gulko 475 Refinitiv 477 EMail: arkadiy.gulko@refinitiv.com