idnits 2.17.1 draft-decraene-mpls-slid-encoded-entropy-label-id-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 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 137: '...ne of those buts MUST allow the choice...' RFC 2119 keyword, line 164: '...ncoding the SLID MUST be configurable ...' RFC 2119 keyword, line 173: '... bit set MUST use the SLID to select...' RFC 2119 keyword, line 179: '... specification SHOULD support the ba...' RFC 2119 keyword, line 189: '...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 (December 16, 2020) is 1227 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 (-09) exists of draft-filsfils-spring-srv6-stateless-slice-id-01 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 3 errors (**), 0 flaws (~~), 2 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: June 19, 2021 W. Henderickx 7 Nokia 8 T. Saad 9 V. Beeram 10 Juniper Networks 11 December 16, 2020 13 Using Entropy Label for Network Slice Identification in MPLS networks. 14 draft-decraene-mpls-slid-encoded-entropy-label-id-00 16 Abstract 18 This document defines a solution to encode a slice identifier in MPLS 19 in order to distinguish packets that belong to different slices, to 20 allow enforcing per network slice policies (.e.g, Qos). 22 The slice identification is independent of the topology. It allows 23 for QoS/DiffServ policy on a per slice basis in addition to the per 24 packet QoS/DiffServ policy provided by the MPLS Traffic Class field. 26 In order to minimize the size of the MPLS stack and to ease 27 incremental deployment the slice identifier is encoded as part of the 28 Entropy Label. 30 This document also extends the use of the TTL field of the Entropy 31 Label in order to provide a flexible set of flags called the Entropy 32 Label Control field. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 19, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Entropy Label Control field . . . . . . . . . . . . . . . . . 3 69 3. Slice Identifier . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.3. Bandwidth-Allocation Slice . . . . . . . . . . . . . . . 4 73 3.4. Backward Compatibility . . . . . . . . . . . . . . . . . 5 74 3.5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. End to end absolute loss measurements . . . . . . . . . . . . 6 76 5. Programmed sampling of packets . . . . . . . . . . . . . . . 6 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 6.2. Informative References . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Segment Routing (SR) [RFC8402] leverages the source-routing paradigm. 85 A node steers a packet through a controlled set of instructions, 86 called segments, by prepending the packet with an SR header. In the 87 SR-MPLS data plane [RFC8660], the SR header is instantiated through a 88 label stack. 90 This document defines a solution to encode a slice identifier in MPLS 91 in order to provide QoS on a per slice basis. It allows for QoS/ 92 DiffServ policy on a per slice basis in addition to the per packet 93 QoS/DiffServ policy provided by the MPLS Traffic Class field. The 94 slice identification is independent of the topology and the QoS of 95 the network, thus enabling scalable network slicing. 97 This document encodes the slice identifier in a portion of the MPLS 98 Entropy Label (EL) defined in [RFC6790]. This has advantages in SR- 99 MPLS networks as it avoids the use of additional label which would 100 increase the size of the label stack. This also reuses the data 101 plane processing of the Entropy Label on the egress LSR, the 102 signaling of the Entropy Label capability from the egress to the 103 ingress [I-D.ietf-isis-mpls-elc] [I-D.ietf-ospf-mpls-elc], and the 104 signaling capability of transit routers to read this label [RFC8491] 105 which allows for an easier and faster incremental deployment. 107 2. Entropy Label Control field 109 [RFC6790] defines the MPLS Entropy Label. [RFC6790] section 4.2 110 defines the use of the Entropy Label Indicator (ELI) followed by the 111 Entropy Label (EL) and the MPLS header fields (Label, TC, S, TTL) in 112 each. [RFC6790] also specifies that the TTL field of the EL must be 113 set to zero by the ingress LSR. 115 Following the procedures of [RFC6790] EL is never used for forwarding 116 and its TTL is never looked at nor decremented: 118 o An EL capable Egress LSR performs a lookup on the ELI and as a 119 result pop two labels: ELI and EL. 121 o An EL non-capable Egress LSR performs a lookup on the ELI and as a 122 result must drop the packet as specified in [RFC3031] for the 123 handling of an invalid incoming label. 125 Hence essentially the TTL field of the EL behaves as a reserved field 126 which must be set to zero when sent and ignored when received. 128 This documents extends the TTL field of the EL and calls it the 129 Entropy Label Control (ELC) field. The ELC is a set of eight flags: 130 ELC0 for bit 0, ELC1 for bit 1,..., ELC7 for bit 7. 132 Given that the MPLS header is very compact (32 bits) with no reserved 133 bits and that MPLS is used within a trusted administrative domain, 134 the semantic of these bits is not standardized but defined on a per 135 administrative domain basis. This allows for increased re-use and 136 flexibility of this scarce resource. As a consequence, an 137 application using one of those buts MUST allow the choice of the bit 138 by configuration by the network operator. 140 3. Slice Identifier 142 Each network slice in an MPLS domain is uniquely identified by a 143 Slice Identifier (SLID). This section proposes to encode the SLID in 144 a portion of the MPLS Entropy Label defined in [RFC6790]. 146 The number of bits to be used for encoding the SLID in the EL is 147 governed by a local policy and uniform within a network slice policy 148 domain. 150 3.1. Ingress LSR 152 When an ingress LSR classifies that a packet belongs to the slice and 153 that the egress has indicated via signaling that it can process EL 154 for the tunnel, the ingress LSR pushes an Entropy Label with the: 156 o SLID encoded in the most significant bits of the Entropy Label. 158 o the entropy information encoded in the remaining lower bits of the 159 Entropy Label as described in section 4.2 of [RFC6790]. 161 o SPI bit (SLID Presence Indicator) set in one bit of the ELC field. 163 The choice of the ELC field used for SPI, and the number of bits to 164 be used for encoding the SLID MUST be configurable by the network 165 operator. 167 The slice classification method is outside the scope of this 168 document. 170 3.2. Transit LSR 172 Any router within the SR domain that forwards a packet with the SPI 173 bit set MUST use the SLID to select a slice and apply per-slice 174 policies. 176 There are many different policies that could define a slice for a 177 particular application or service. The most basic of these is 178 bandwidth-allocation, an implementation complying with this 179 specification SHOULD support the bandwidth-allocation slice as 180 defined in the next section. 182 3.3. Bandwidth-Allocation Slice 184 A per-slice policy is configured at each interface of each router in 185 the SR domain, with one traffic shaper per SLID. The bit rate of 186 each shaper is configured to reflect the bandwidth allocation of the 187 per-slice policy. 189 If shapers are not available, or desirable, an implementation MAY 190 configure one scheduling queue per SLID with a guaranteed bandwidth 191 equal to the bandwidth-allocation for the slice. This option allows 192 a slice to consume more bandwidth than its allocation when available. 194 Per-slice shapers or queues effectively provides a virtual port per 195 slice. This solution MAY be complemented with a per-virtual-port 196 hierarchical DiffServ policy. Within the context of one specific 197 slice, packets are further classified into children DiffServ queues 198 which hang from the virtual port. The Traffic Class value in the 199 MPLS header SHOULD be used for queue selection. 201 3.4. Backward Compatibility 203 The Entropy Label usage described in this document is consistent with 204 [RFC6790] as ingress LSRs freely chooses the EL of a given flow, and 205 transit LSRs treat the EL as an opaque set of bits. 207 As per [RFC6790] an ingress LSR that does not support this extension 208 has the SPI bit cleared, and thus does not enable the SLID semantic 209 of the Entropy bits. Hence, SLID-aware transit LSRs will not 210 classify these packets into a slice. 212 3.5. Benefits 214 From a Segment Routing architecture perspective, this network slice 215 identifier for SR-MPLS is inline with the network slice identifier 216 for SRv6 proposed in [I-D.filsfils-spring-srv6-stateless-slice-id]. 218 From an SR-MPLS perspective, using the EL to carry the network slice 219 identifier has multiple benefits: 221 o This limits the number of labels pushed on the MPLS stack compared 222 to using a pair of labels (ELI+EL) for flow entropy plus two or 223 three labels for the slice indicator and the slice identifier. 224 This is beneficial for the ingress LSR which may have limitations 225 with regards to the number of labels pushed, for the transit LSR 226 which may have limitations with regards to the label stack depth 227 to be examined during transit in order to read both the entropy 228 and the SLID. This presents additional benefit to network 229 operators by reducing the packet overhead for traffic carried 230 through the network; 232 o This avoids defining new extensions for the signaling of the 233 egress capability to support the slice indicator and the slice 234 identifier; 236 o This improves incremental deployment as all egress LSRs supporting 237 EL can be sent the slice identifier from day one, allowing slice 238 classification on transit LSRs. 240 4. End to end absolute loss measurements 242 This section describes the usage of a ELC flag to enable packet loss 243 measurements, as described in section 3.1 of [RFC8321], for SR-MPLS 244 networks. 246 TBD 248 5. Programmed sampling of packets 250 This section describes the usage of a ELC flag to detect end to end 251 packet loss. 253 TBD 255 6. References 257 6.1. Normative References 259 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 260 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 261 RFC 6790, DOI 10.17487/RFC6790, November 2012, 262 . 264 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 265 Decraene, B., Litkowski, S., and R. Shakir, "Segment 266 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 267 July 2018, . 269 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 270 Decraene, B., Litkowski, S., and R. Shakir, "Segment 271 Routing with the MPLS Data Plane", RFC 8660, 272 DOI 10.17487/RFC8660, December 2019, 273 . 275 6.2. Informative References 277 [I-D.filsfils-spring-srv6-stateless-slice-id] 278 Filsfils, C., Clad, F., Camarillo, P., and K. Raza, 279 "Stateless and Scalable Network Slice Identification for 280 SRv6", draft-filsfils-spring-srv6-stateless-slice-id-01 281 (work in progress), July 2020. 283 [I-D.ietf-isis-mpls-elc] 284 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 285 and M. Bocci, "Signaling Entropy Label Capability and 286 Entropy Readable Label Depth Using IS-IS", draft-ietf- 287 isis-mpls-elc-13 (work in progress), May 2020. 289 [I-D.ietf-ospf-mpls-elc] 290 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 291 and M. Bocci, "Signaling Entropy Label Capability and 292 Entropy Readable Label Depth Using OSPF", draft-ietf-ospf- 293 mpls-elc-15 (work in progress), June 2020. 295 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 296 Label Switching Architecture", RFC 3031, 297 DOI 10.17487/RFC3031, January 2001, 298 . 300 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 301 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 302 "Alternate-Marking Method for Passive and Hybrid 303 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 304 January 2018, . 306 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 307 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 308 DOI 10.17487/RFC8491, November 2018, 309 . 311 Authors' Addresses 313 Bruno Decraene (editor) 314 Orange 316 Email: bruno.decraene@orange.com 318 Clarence Filsfils 319 Cisco Systems, Inc. 320 Belgium 322 Email: cf@cisco.com 324 Wim Henderickx 325 Nokia 326 Copernicuslaan 50 327 Antwerp 2018, CA 95134 328 Belgium 330 Email: wim.henderickx@nokia.com 331 Tarek Saad 332 Juniper Networks 334 Email: tsaad@juniper.net 336 Vishnu Pavan Beeram 337 Juniper Networks 339 Email: vbeeram@juniper.net