idnits 2.17.1 draft-decraene-mpls-slid-encoded-entropy-label-id-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 140: '...ne of those buts MUST allow the choice...' RFC 2119 keyword, line 168: '...ncoding the SLID MUST be configurable ...' RFC 2119 keyword, line 186: '... bit set MUST use the SLID to select...' RFC 2119 keyword, line 192: '... specification SHOULD support the ba...' RFC 2119 keyword, line 202: '...e, or desirable, an implementation MAY...' (2 more instances...) -- The draft header indicates that this document updates RFC6790, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 August 2021) is 965 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 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-stateless-slice-id-04 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS B. Decraene, Ed. 3 Internet-Draft Orange 4 Updates: 6790 (if approved) C. Filsfils 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: 7 February 2022 W. Henderickx 7 Nokia 8 T. Saad 9 V. Beeram 10 Juniper Networks 11 L. Jalil 12 Verizon 13 6 August 2021 15 Using Entropy Label for Network Slice Identification in MPLS networks. 16 draft-decraene-mpls-slid-encoded-entropy-label-id-02 18 Abstract 20 This document defines a solution to encode a slice identifier in MPLS 21 in order to distinguish packets that belong to different slices, to 22 allow enforcing per network slice policies (.e.g, Qos). 24 The slice identification is independent of the topology. It allows 25 for QoS/DiffServ policy on a per slice basis in addition to the per 26 packet QoS/DiffServ policy provided by the MPLS Traffic Class field. 28 In order to minimize the size of the MPLS stack and to ease 29 incremental deployment the slice identifier is encoded as part of the 30 Entropy Label. 32 This document also extends the use of the TTL field of the Entropy 33 Label in order to provide a flexible set of flags called the Entropy 34 Label Control field. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 7 February 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Entropy Label Control field . . . . . . . . . . . . . . . . . 3 71 3. Slice Identifier . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.3. Bandwidth-Allocation Slice . . . . . . . . . . . . . . . 5 75 3.4. Backward Compatibility . . . . . . . . . . . . . . . . . 5 76 3.5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4. End to end absolute loss measurements . . . . . . . . . . . . 6 78 5. Programmed sampling of packets . . . . . . . . . . . . . . . 6 79 6. Changes / Authors Notes . . . . . . . . . . . . . . . . . . . 6 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 7.2. Informative References . . . . . . . . . . . . . . . . . 7 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Introduction 87 Segment Routing (SR) [RFC8402] leverages the source-routing paradigm. 88 A node steers a packet through a controlled set of instructions, 89 called segments, by prepending the packet with an SR header. In the 90 SR-MPLS data plane [RFC8660] , the SR header is instantiated through 91 a label stack. 93 This document defines a solution to encode a slice identifier in MPLS 94 in order to provide QoS on a per slice basis. It allows for QoS/ 95 DiffServ policy on a per slice basis in addition to the per packet 96 QoS/DiffServ policy provided by the MPLS Traffic Class field. The 97 slice identification is independent of the topology and the QoS of 98 the network, thus enabling scalable network slicing. 100 This document encodes the slice identifier in a portion of the MPLS 101 Entropy Label (EL) defined in [RFC6790] . This has advantages in SR- 102 MPLS networks as it avoids the use of additional label which would 103 increase the size of the label stack. This also reuses the data 104 plane processing of the Entropy Label on the egress LSR, the 105 signaling of the Entropy Label capability from the egress to the 106 ingress [I-D.ietf-isis-mpls-elc] [I-D.ietf-ospf-mpls-elc] , and the 107 signaling capability of transit routers to read this label [RFC8491] 108 which allows for an easier and faster incremental deployment. 110 2. Entropy Label Control field 112 [RFC6790] defines the MPLS Entropy Label. [RFC6790] section 4.2 113 defines the use of the Entropy Label Indicator (ELI) followed by the 114 Entropy Label (EL) and the MPLS header fields (Label, TC, S, TTL) in 115 each. [RFC6790] also specifies that the TTL field of the EL must be 116 set to zero by the ingress LSR. 118 Following the procedures of [RFC6790] EL is never used for forwarding 119 and its TTL is never looked at nor decremented: 121 * An EL capable Egress LSR performs a lookup on the ELI and as a 122 result pop two labels: ELI and EL. 124 * An EL non-capable Egress LSR performs a lookup on the ELI and as a 125 result must drop the packet as specified in [RFC3031] for the 126 handling of an invalid incoming label. 128 Hence essentially the TTL field of the EL behaves as a reserved field 129 which must be set to zero when sent and ignored when received. 131 This documents extends the TTL field of the EL and calls it the 132 Entropy Label Control (ELC) field. The ELC is a set of eight flags: 133 ELC0 for bit 0, ELC1 for bit 1,..., ELC7 for bit 7. 135 Given that the MPLS header is very compact (32 bits) with no reserved 136 bits and that MPLS is used within a trusted administrative domain, 137 the semantic of these bits is not standardized but defined on a per 138 administrative domain basis. This allows for increased re-use and 139 flexibility of this scarce resource. As a consequence, an 140 application using one of those buts MUST allow the choice of the bit 141 by configuration by the network operator. 143 3. Slice Identifier 145 Each network slice in an MPLS domain is uniquely identified by a 146 Slice Identifier (SLID) [I-D.bestbar-teas-ns-packet] . This section 147 encodes the SLID in a portion of the MPLS Entropy Label defined in 148 [RFC6790] . 150 The number of bits to be used for encoding the SLID in the EL is 151 governed by a local policy and uniform within a network slice policy 152 domain. 154 3.1. Ingress LSR 156 When an ingress LSR classifies that a packet belongs to the slice and 157 that the egress has indicated via signaling that it can process EL 158 for the tunnel, the ingress LSR pushes an Entropy Label with the: 160 * SLID encoded in the most significant bits of the Entropy Label. 162 * the entropy information encoded in the remaining lower bits of the 163 Entropy Label as described in section 4.2 of [RFC6790] . 165 * SPI bit (SLID Presence Indicator) set in one bit of the ELC field. 167 The choice of the ELC field used for SPI, and the number of bits to 168 be used for encoding the SLID MUST be configurable by the network 169 operator. 171 The slice classification method is outside the scope of this 172 document. 174 The encoding of the Slide ID in the Entropy Label is in line with the 175 specification of the Flow Label as the slide identification _is_ a 176 property of the flow: 178 * For a given flow it is constant in all packets. 180 * It's a property specific to the flow so would typically be used to 181 determine the Entropy Label. 183 3.2. Transit LSR 185 Any router within the SR domain that forwards a packet with the SPI 186 bit set MUST use the SLID to select a slice and apply per-slice 187 policies. 189 There are many different policies that could define a slice for a 190 particular application or service. The most basic of these is 191 bandwidth-allocation, an implementation complying with this 192 specification SHOULD support the bandwidth-allocation slice as 193 defined in the next section. 195 3.3. Bandwidth-Allocation Slice 197 A per-slice policy is configured at each interface of each router in 198 the SR domain, with one traffic shaper per SLID. The bit rate of 199 each shaper is configured to reflect the bandwidth allocation of the 200 per-slice policy. 202 If shapers are not available, or desirable, an implementation MAY 203 configure one scheduling queue per SLID with a guaranteed bandwidth 204 equal to the bandwidth-allocation for the slice. This option allows 205 a slice to consume more bandwidth than its allocation when available. 207 Per-slice shapers or queues effectively provides a virtual port per 208 slice. This solution MAY be complemented with a per-virtual-port 209 hierarchical DiffServ policy. Within the context of one specific 210 slice, packets are further classified into children DiffServ queues 211 which hang from the virtual port. The Traffic Class value in the 212 MPLS header SHOULD be used for queue selection. 214 3.4. Backward Compatibility 216 The Entropy Label usage described in this document is consistent with 217 [RFC6790] as ingress LSRs freely chooses the EL of a given flow, and 218 transit LSRs treat the EL as an opaque set of bits. 220 As per [RFC6790] an ingress LSR that does not support this extension 221 has the SPI bit cleared, and thus does not enable the SLID semantic 222 of the Entropy bits. Hence, SLID-aware transit LSRs will not 223 classify these packets into a slice. 225 3.5. Benefits 227 From a Segment Routing architecture perspective, this network slice 228 identifier for SR-MPLS is inline with the network slice identifier 229 for SRv6 proposed in [I-D.filsfils-spring-srv6-stateless-slice-id] . 231 From an SR-MPLS perspective, using the EL to carry the network slice 232 identifier has multiple benefits: 234 * This limits the number of labels pushed on the MPLS stack compared 235 to using a pair of labels (ELI+EL) for flow entropy plus two or 236 three labels for the slice indicator and the slice identifier. 237 This is beneficial for the ingress LSR which may have limitations 238 with regards to the number of labels pushed, for the transit LSR 239 which may have limitations with regards to the label stack depth 240 to be examined during transit in order to read both the entropy 241 and the SLID. This presents additional benefit to network 242 operators by reducing the packet overhead for traffic carried 243 through the network; 245 * This avoids defining new extensions for the signaling of the 246 egress capability to support the slice indicator and the slice 247 identifier; 249 * This improves incremental deployment as all egress LSRs supporting 250 EL can be sent the slice identifier from day one, allowing slice 251 classification on transit LSRs. 253 4. End to end absolute loss measurements 255 This section describes the usage of a ELC flag to enable packet loss 256 measurements, as described in section 3.1 of [RFC8321] , for SR-MPLS 257 networks. 259 TBD 261 5. Programmed sampling of packets 263 This section describes the usage of a ELC flag to detect end to end 264 packet loss. 266 TBD 268 6. Changes / Authors Notes 270 [RFC Editor: Please remove this section before publication] 272 00: Initial version. 274 01: New co-author 276 02: editorial precision that the slice ID is a component of flow 277 entropy hence inline with the use of entropy label. 279 7. References 281 7.1. Normative References 283 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 284 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 285 RFC 6790, DOI 10.17487/RFC6790, November 2012, 286 . 288 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 289 Decraene, B., Litkowski, S., and R. Shakir, "Segment 290 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 291 July 2018, . 293 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 294 Decraene, B., Litkowski, S., and R. Shakir, "Segment 295 Routing with the MPLS Data Plane", RFC 8660, 296 DOI 10.17487/RFC8660, December 2019, 297 . 299 7.2. Informative References 301 [I-D.bestbar-teas-ns-packet] 302 Saad, T., Beeram, V. P., Wen, B., Ceccarelli, D., Halpern, 303 J., Peng, S., Chen, R., Liu, X., Contreras, L. M., and R. 304 Rokui, "Realizing Network Slices in IP/MPLS Networks", 305 Work in Progress, Internet-Draft, draft-bestbar-teas-ns- 306 packet-03, 11 July 2021, . 309 [I-D.filsfils-spring-srv6-stateless-slice-id] 310 Filsfils, C., Clad, F., Camarillo, P., Raza, K., Voyer, 311 D., and R. Rokui, "Stateless and Scalable Network Slice 312 Identification for SRv6", Work in Progress, Internet- 313 Draft, draft-filsfils-spring-srv6-stateless-slice-id-04, 314 30 July 2021, . 317 [I-D.ietf-isis-mpls-elc] 318 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 319 and M. Bocci, "Signaling Entropy Label Capability and 320 Entropy Readable Label Depth Using IS-IS", Work in 321 Progress, Internet-Draft, draft-ietf-isis-mpls-elc-13, 28 322 May 2020, . 325 [I-D.ietf-ospf-mpls-elc] 326 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 327 and M. Bocci, "Signaling Entropy Label Capability and 328 Entropy Readable Label Depth Using OSPF", Work in 329 Progress, Internet-Draft, draft-ietf-ospf-mpls-elc-15, 1 330 June 2020, . 333 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 334 Label Switching Architecture", RFC 3031, 335 DOI 10.17487/RFC3031, January 2001, 336 . 338 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 339 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 340 "Alternate-Marking Method for Passive and Hybrid 341 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 342 January 2018, . 344 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 345 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 346 DOI 10.17487/RFC8491, November 2018, 347 . 349 Authors' Addresses 351 Bruno Decraene (editor) 352 Orange 354 Email: bruno.decraene@orange.com 356 Clarence Filsfils 357 Cisco Systems, Inc. 358 Belgium 360 Email: cf@cisco.com 362 Wim Henderickx 363 Nokia 364 Copernicuslaan 50 365 95134 Antwerp 2018 366 Belgium 368 Email: wim.henderickx@nokia.com 369 Tarek Saad 370 Juniper Networks 372 Email: tsaad@juniper.net 374 Vishnu Pavan Beeram 375 Juniper Networks 377 Email: vbeeram@juniper.net 379 Luay Jalil 380 Verizon 382 Email: luay.jalil@verizon.com