idnits 2.17.1 draft-zzhang-bier-slicing-and-differentiation-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 (September 29, 2021) is 933 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 (-10) exists of draft-bestbar-teas-ns-packet-03 ** Downref: Normative reference to an Informational draft: draft-bestbar-teas-ns-packet (ref. 'I-D.bestbar-teas-ns-packet') == Outdated reference: A later version (-03) exists of draft-zzhang-intarea-generic-delivery-functions-02 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-04 == Outdated reference: A later version (-07) exists of draft-li-apn-framework-03 == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 bier Z. Zhang 3 Internet-Draft A. Przygienda 4 Intended status: Standards Track Juniper Networks 5 Expires: April 2, 2022 September 29, 2021 7 BIER with Network Slicing and Flow Differentiation 8 draft-zzhang-bier-slicing-and-differentiation-00 10 Abstract 12 This document specifies how BIER works in the context of IETF Network 13 slicing, with or without fined-grained traffic differentiation. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 2, 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. BIER with IETF Network Slicing . . . . . . . . . . . . . . . 3 51 3. BIER with Slice Aggregates . . . . . . . . . . . . . . . . . 4 52 4. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4 53 4.1. ISIS Signaling . . . . . . . . . . . . . . . . . . . . . 4 54 4.1.1. OSPF Signaling . . . . . . . . . . . . . . . . . . . 5 55 4.1.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . 5 56 4.2. BIER Extension Header . . . . . . . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 Network slicing has been a topic widely discussed in and beyond IETF. 67 According to [I-D.ietf-teas-ietf-network-slices]: 69 "An IETF Network Slice is a logical network topology connecting a 70 number of endpoints using a set of shared or dedicated network 71 resources that are used to satisfy specific Service Level Objectives 72 (SLOs). 74 An IETF Network Slice combines the connectivity resource requirements 75 and associated network behaviors such as bandwidth, latency, jitter, 76 and network functions with other resource behaviors such as compute 77 and storage availability." 79 It is expected that traffic associated with an IETF network slice is 80 identified with a slice identifier (e.g. an MPLS label) and each node 81 in the path uses the slice identifier to identify the slice in which 82 the traffic is forwarded. 84 [I-D.bestbar-teas-ns-packet] introduces the notion of Slice Aggregate 85 which comprises of one of more IETF network slice traffic streams. A 86 Slice Aggregate is identified by a Slice Selector (SS), and packets 87 carry the SS so that associated forwarding treatment or S-PHB (Slice 88 policy Per Hop Behavior - the externally observable forwarding 89 behavior applied to a specific packet belonging to a slice aggregate) 90 - can be applied along the path. 92 [I-D.li-apn-problem-statement-usecases] describes challenges faced by 93 network operators when attempting to provide fine-grained traffic 94 operations to satisfy the various requirements demanded by new 95 applications that require differentiated service treatment and 96 [I-D.li-apn-framework] proposes a framework for solution: 98 "... proposes a new framework, named Application-aware 99 Networking (APN), where application-aware information (i.e. APN 100 attribute) including APN identification (ID) and/or APN parameters 101 (e.g. network performance requirements) is encapsulated at network 102 edge devices and carried in packets traversing an APN domain in order 103 to facilitate service provisioning, perform fine-granularity traffic 104 steering and network resource adjustment." 106 The authors of this document believe that the IETF Network Slicing 107 framework, when augmented by the Slice Aggregate, addresses the APN 108 problem domain very well. This documents describes how BIER 109 [RFC8279] works together with IETF network slicing, with or without 110 Slice Aggregate to provide fine granularity traffic differentiation 111 (e.g. down to per-flow level) that is demanded in the APN problem 112 statement. 114 2. BIER with IETF Network Slicing 116 Since an IETF Network Slice is a logical network topology, each slice 117 may have its BIRT (which maps to a set of BIFTs when BitStringLength 118 and SetID are considered). While it is tempting and seems logical to 119 map a slice to a BIER sub-domain, and it is straightforward to do so 120 when the number of slices is smaller than 256 (the max number of sub- 121 domains), this document allows to map a slice directly to a BIRT 122 instead of a sub-domain. 124 Now a BIRT corresponds to a tuple, and each BIFT 125 corresponds to a 126 tuple. In forwarding plane a BIFT is only identified by a 20-bit 127 opaque number locally on a BFR, which could be an MPLS label or just 128 a plain number in case of non-MPLS data plane. Therefore, it is 129 feasible to have many slices in the same sub-domain - each slice will 130 have its own BIRT so that the same BFER in the same sub-domain can be 131 reached via different nexthop BFRs according to different BIRTs (i.e. 132 different set of corresponding BIFTs) for different slices. 134 With this, up to 2^20 slices could be supported in theory - the only 135 limit is the number of BIFT entries that a BFR can hold. 137 Mapping a slice directly to a BIRT instead of a sub-domain not only 138 allows more than 256 slices but also reduces the burden of sub-domain 139 related provisioning (e.g. a BFR-ID is needed for each ). Of course, as mentioned earlier, if the number of 141 slices is smaller than 256 then a slice can map to a sub-domain as 142 well. 144 3. BIER with Slice Aggregates 146 Per [I-D.bestbar-teas-ns-packet], a Slice Aggregate may be the 147 aggregation of several entire slices, or just a particular flow in a 148 slice. With a Slice Aggregate for several entire slices, the 149 different slices (of the same Slice Aggregate) also map to the same 150 BIRT. In that case, for the same destination BFER, traffic in those 151 different slices are forwarded to the same (set of ECMP) nexthop BFER 152 according to the shared BIRT, yet other forwarding treatment (e.g. 153 queuing) could still be different. 155 In [RFC8279], a sub-domain is associated with only one topology and 156 each sub-domain has its own BIRT calculated using the topology 157 information. When multiple slices are associated with a single sub- 158 domain, each slice (or a set of slices) also has its own BIRT 159 calculated based on the slice's (or the set of slices') topology 160 information. Therefore, having a sub-domain with multiple slices 161 does not violate the underlying principle of BIER architecture, i.e., 162 a BIRT is calculated on a corresponding topology, whether the 163 topology is for a sub-domain as in [RFC8279] or for a tuple as in this document. 166 The BIER header has a 6-bit DSCP field. If that is not enough to 167 identify different slices or slice aggregates that share the same 168 BIRT, an explicit Slice Selector can be carried in "BIER Extension 169 Header" [I-D.zzhang-intarea-generic-delivery-functions]. 171 This means that, even for a transit BFR, if provisioned to support 172 slice aggregates identified by a Slice Selector in the extension 173 header, it must check if the "Proto" field is set to a value for BIER 174 Extension Header. 176 Note: while the concept of "BIER Extension Header" is first brought 177 up in that Generic Delivery Functions draft 178 [I-D.zzhang-intarea-generic-delivery-functions] in intarea WG, it is 179 expected that BIER specific work will be brought to the BIER WG. 181 4. Specifications 183 BIER signaling for OSPF/ISIS/BGP is extended to include slice 184 information so that slice-specific BIRTs can be built. 186 4.1. ISIS Signaling 188 A BIER MPLS Encapsulation Extended Sub-sub-TLV is defined with a new 189 type to allow sub-sub-sub-TLVs in it. Besides the new type and 190 additional sub-sub-sub-TLVs, the rest are the same as original BIER 191 MPLS Encapsulation Sub-sub-TLV [RFC8401]. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Max SI |BS Len | Label | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | sub-sub-sub-TLVs (variable) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Type: Value of TBD indicating Extended sub-sub-TLV for MPLS 205 Length: Variable 207 Sub-sub-sub-TLVs: for information like Slice Selector 209 Sub-sub-sub-TLVs will be defined to include Slice Selector 210 information [I-D.bestbar-teas-ns-packet] that identifies a slice or a 211 Slice Aggregate, and potentially other information. Note that the 212 Slice Aggregate here is for a set of slices instead of a flow in a 213 slice. Future revisions will have more details. 215 Similar encoding will be defined for non-MPLS encapsulation in future 216 revisions. 218 4.1.1. OSPF Signaling 220 Similar encoding will be defined for OSPF signaling in future 221 revisions. 223 4.1.2. BGP Signaling 225 Similar encoding will be defined for BGP signaling in future 226 revisions. 228 4.2. BIER Extension Header 230 This will be tracked by a separate BIER draft. For now, please refer 231 to [I-D.zzhang-intarea-generic-delivery-functions]. 233 5. Security Considerations 235 To be provided. 237 6. IANA Considerations 239 To be provided. 241 7. References 243 7.1. Normative References 245 [I-D.bestbar-teas-ns-packet] 246 Saad, T., Beeram, V. P., Wen, B., Ceccarelli, D., Halpern, 247 J., Peng, S., Chen, R., Liu, X., Contreras, L. M., and R. 248 Rokui, "Realizing Network Slices in IP/MPLS Networks", 249 draft-bestbar-teas-ns-packet-03 (work in progress), July 250 2021. 252 [I-D.zzhang-intarea-generic-delivery-functions] 253 Zhang, Z., Bonica, R., Kompella, K., and G. Mirsky, 254 "Generic Delivery Functions", draft-zzhang-intarea- 255 generic-delivery-functions-02 (work in progress), August 256 2021. 258 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 259 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 260 Explicit Replication (BIER)", RFC 8279, 261 DOI 10.17487/RFC8279, November 2017, 262 . 264 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 265 Zhang, "Bit Index Explicit Replication (BIER) Support via 266 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 267 . 269 7.2. Informative References 271 [I-D.ietf-teas-ietf-network-slices] 272 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 273 Makhijani, K., Contreras, L. M., and J. Tantsura, 274 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 275 network-slices-04 (work in progress), August 2021. 277 [I-D.li-apn-framework] 278 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 279 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 280 "Application-aware Networking (APN) Framework", draft-li- 281 apn-framework-03 (work in progress), May 2021. 283 [I-D.li-apn-problem-statement-usecases] 284 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 285 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 286 "Problem Statement and Use Cases of Application-aware 287 Networking (APN)", draft-li-apn-problem-statement- 288 usecases-04 (work in progress), June 2021. 290 Authors' Addresses 292 Zhaohui Zhang 293 Juniper Networks 295 Email: zzhang@juniper.net 297 Antoni Przygienda 298 Juniper Networks 300 Email: prz@juniper.net