idnits 2.17.1 draft-jiang-mpls-entropy-block-01.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 (June 30, 2020) is 1393 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. He, Ed. 3 Internet-Draft B. Nie 4 Intended status: Standards Track Z. Zhao 5 Expires: January 1, 2021 Ericsson 6 June 30, 2020 8 MPLS Entropy Block 9 draft-jiang-mpls-entropy-block-01 11 Abstract 13 Load balancing across MPLS networks requires entropy information to 14 be carried in MPLS label stack and to be handled by the downstream 15 Label Switching Routers. This document describes the problems using 16 existing approaches and introduces an approach to the solution. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 1, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. End-to-End Processing . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Example 1 Entropy Block advertisement through signaling . 3 57 4.2. Example 2 Entropy Block advertisement through global 58 configuration . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Signaling for Entropy Block . . . . . . . . . . . . . . . . . 5 60 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Anycast Segment . . . . . . . . . . . . . . . . . . . . . 5 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 9.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Traffic load balancing improves bandwidth utilization in MPLS 72 networks. The entropy information is required to be carried in MPLS 73 label stack of each packet in the MPLS network, and to be handled 74 along the path by Label Switching Routers (LSR) towards egress node. 75 [RFC6790] provides a technique used in the MPLS data plane to provide 76 entropy for load-balancing, using a combination of Entropy Label 77 Indicator and Entropy Label. [RFC6391] provides another technique 78 used in the MPLS data plane while only serve for pseudowire based 79 services. 81 An LSR may have limitations in the number of labels it can push. It 82 may also have a limitation in the number of labels it can inspect 83 when looking for entropy information. The limitations become obvious 84 for traffic-engineering applications such as Segment Routing 85 [RFC8402] and Resource ReserVation Protocol-Traffic Engineering 86 (RSVP-TE) [RFC3209]. Some proposals are discussed in [RFC8662]. 88 This document describes an approach to mitigate the limitations, by 89 allocating a specific MPLS label block for entropy usage. Thus the 90 entropy information can be carried in the MPLS label stack and 91 handled by the downstream LSRs. It adds additional alternatives 92 beyond those discussed in [RFC6790] section 2. This single entropy 93 label approach improves efficiency when compared with [RFC6790] which 94 uses label pair (ELI/EL). It also accommodates label location 95 flexibility and service agnostic when compared with [RFC6391]. 96 Considerations from [RFC8662] are still applicable, whether it is 97 ELI/EL or EL only. As described there, systems involved still need 98 to carefully consider issues such as MSD, and determine how many 99 entropy labels are needed, and where they need to be placed. This 100 draft reduces the overhead of these labels from 2 labels to 1. 102 In the document we see some issues with all the alternatives and are 103 looking for further discussion. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 3. Approach 115 The entropy information is encoded as an additional label in MPLS 116 label stack. Since the single Entropy Label (EL) is encapsulated by 117 an ingress LSR while terminated at an egress LSR, both ingress LSR 118 and egress LSR MUST be able to distinguish unambiguously between 119 entropy label and other labels. To accomplish this, a dedicated 120 label range is allocated for entropy label, named Entropy Block (EB). 122 The Entropy Block can be advertised through signals (E.g. through 123 IGP) or globally configured (E.g. through NMS). 125 On ingress LSR, when encoding entropy information in MPLS label stack 126 towards an egress LSR, the label value shall be in the range of the 127 Entropy Block. When received on the egress LSR and the entropy label 128 appears from the MPLS label stack, it is simply popped. 130 4. End-to-End Processing 132 4.1. Example 1 Entropy Block advertisement through signaling 134 In this example, Entropy Block is advertised by each LSR through IGP 135 (E.g. IS-IS). Each LSR may have different Entropy Block. One 136 traffic flow is forwarded through a Traffic Engineering (TE) tunnel, 137 LSR1->LSR4->LSR6. 139 On ingress LSR, entropy value is calculated from packet received, and 140 adjusted to the Entropy Block of LSR6 as it is to be popped by LSR6. 142 On transit LSRs, such as LSR2 or LSR3, the entropy information in the 143 packet is utilized for load balancing. When packet reaches LSR4, the 144 steering point of the TE tunnel, the topmost tunnel label is popped 145 and packet continues to egress LSR, LSR6. After the second tunnel 146 label is popped, the entropy label is popped and packet is sent out. 148 | ------------------ IGP ---------------------- | 150 +===== LSR4 ======+ 151 | | 152 LSR1 ==== LSR2 ==== LSR3 ============ LSR5 ==== LSR6 154 --> +---------+ +---------+ --> 155 Pkt | Payload | | Payload | Pkt 156 +---------+ +---------+ 157 | EL6 | | EL6 | 158 +---------+ +---------+ 159 | LSR6 | | LSR6 | 160 +---------+ +---------+ 161 | LSR4 | 162 +---------+ 164 Figure 1: Single EL for TE tunnel LSR1->LSR4->LSR6 166 4.2. Example 2 Entropy Block advertisement through global configuration 168 In this example, Entropy Block is globally configured by NMS. All 169 LSRs have the identical Entropy Block. One traffic flow is forwarded 170 through a Traffic Engineering (TE) tunnel, LSR1->LSR4->LSR6. LSR2 171 and LSR3 have Less entropy reachability capability. 173 Considering the entropy reachability capability on some LSRs, more 174 entropy labels are encapsulated in the MPLS stack. On ingress LSR, 175 entropy value is calculated from packet received, and adjusted to 176 Entropy Block globally configured. 178 On transit LSRs, such as LSR2 or LSR3, the entropy information in the 179 packet is utilized for load balancing. When packet reaches LSR4, the 180 steering point of the TE tunnel, the topmost tunnel label is popped 181 and the first entropy label is popped. Then packet continues to 182 egress LSR, LSR6. After the second tunnel label is popped, the 183 second entropy label is popped and packet is sent out. 185 +----------------+ 186 | NMS | 187 +----------------+ 188 / | \ 190 +===== LSR4 ======+ 191 | | 192 LSR1 ==== LSR2 ==== LSR3 ============ LSR5 ==== LSR6 194 --> +---------+ +---------+ --> 195 Pkt | Payload | | Payload | Pkt 196 +---------+ +---------+ 197 | ELx | | ELx | 198 +---------+ +---------+ 199 | LSR6 | | LSR6 | 200 +---------+ +---------+ 201 | ELx | 202 +---------+ 203 | LSR4 | 204 +---------+ 206 Figure 2: Multiple ELs for TE tunnel LSR1->LSR4->LSR6 208 5. Signaling for Entropy Block 210 The Entropy Block is advertised through signals (E.g. IGP) with new 211 extensions. It could be represented as range size together with base 212 label value, or the two boundary label values. 214 The detail formats of the extensions are left for further discussion. 216 6. Issues 218 6.1. Anycast Segment 220 In Segment Routing networks [RFC8402] when anycast segment is 221 deployed, special care is required. 223 An anycast segment is not reference a particular node, but a group of 224 nodes. In case each node in the group has different Entropy Block, 225 ingress LSR cannot encapsulate an appropriate entropy label behind 226 the anycast segment in the MPLS stack. 228 To ease the use of Entropy Block with anycast segment, it is 229 recommended to configure identical Entropy Block on all nodes of a 230 particular anycast group. Using an anycast segment without 231 configuring identical Entropy Block on all nodes belonging to the 232 same anycast group may lead to misrouting. 234 7. IANA Considerations 236 TBD. 238 8. Security Considerations 240 With the use of the extensions defined in this document, Entropy 241 information will be used to program the MPLS data plane [RFC3031]. 242 Using an anycast segment without configuring identical Entropy Block 243 on all nodes belonging to the same anycast group may lead to 244 misrouting. 246 9. References 248 9.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 256 Label Switching Architecture", RFC 3031, 257 DOI 10.17487/RFC3031, January 2001, 258 . 260 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 261 Regan, J., and S. Amante, "Flow-Aware Transport of 262 Pseudowires over an MPLS Packet Switched Network", 263 RFC 6391, DOI 10.17487/RFC6391, November 2011, 264 . 266 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 267 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 268 RFC 6790, DOI 10.17487/RFC6790, November 2012, 269 . 271 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 272 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 273 May 2017, . 275 9.2. Informative References 277 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 278 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 279 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 280 . 282 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 283 Decraene, B., Litkowski, S., and R. Shakir, "Segment 284 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 285 July 2018, . 287 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 288 Shakir, R., and J. Tantsura, "Entropy Label for Source 289 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 290 DOI 10.17487/RFC8662, December 2019, 291 . 293 Authors' Addresses 295 Jiang He (editor) 296 Ericsson 297 No. 5, Lize east street, Chaoyang district 298 Beijing 100102 299 CN 301 Email: jiang.he@ericsson.com 303 Bolin Nie 304 Ericsson 305 No. 5, Lize east street, Chaoyang district 306 Beijing 100102 307 CN 309 Email: zephyr.nie@ericsson.com 311 Zhenning Zhao 312 Ericsson 313 No. 5, Lize east street, Chaoyang district 314 Beijing 100102 315 CN 317 Email: navid.zhao@ericsson.com