idnits 2.17.1 draft-kini-mpls-entropy-label-src-stacked-tunnels-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 (August 29, 2013) is 3892 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.previdi-isis-segment-routing-extensions' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'I-D.psenak-ospf-segment-routing-extensions' is defined on line 261, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-filsfils-rtgwg-segment-routing-use-cases-01 == Outdated reference: A later version (-01) exists of draft-filsfils-rtgwg-segment-routing-00 == Outdated reference: A later version (-05) exists of draft-previdi-isis-segment-routing-extensions-02 == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kini, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational K. Kompella 5 Expires: March 02, 2014 Juniper 6 S. Sivabalan 7 Cisco 8 August 29, 2013 10 Entropy labels for source routed stacked tunnels 11 draft-kini-mpls-entropy-label-src-stacked-tunnels-01 13 Abstract 15 Source routed tunnel stacking is a technique that can be leveraged to 16 provide a method to steer a packet through a controlled set of 17 segments. This can be applied to the Multi Protocol Label Switching 18 (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to 19 improve load balancing. This document examines how ELs are to be 20 applied to source routed stacked tunnels. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 02, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 58 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 2 59 3. Entropy Labels for source routed stacked tunnels . . . . . . 3 60 3.1. Single EL at the bottom of the stack of tunnels . . . . . 4 61 3.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 4 62 3.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 4 63 3.4. ELs at readable label stack depths . . . . . . . . . . . 5 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 7.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The source routed stacked tunnels paradigm is leveraged by techniques 75 such as Segment Routing (SR) [I-D.filsfils-rtgwg-segment-routing] to 76 steer a packet through a set of segments. This can be directly 77 applied to the MPLS data plane. Entropy labels (EL) [RFC6790] is a 78 technique used by the MPLS data plane to do load balancing. Applying 79 ELs to stacked tunnels brings up some issues and these are documented 80 in Section 3. 82 1.1. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 2. Abbreviations and Terminology 90 EL - Entropy Label 92 ELI - Entropy Label Identifier 94 SR - Segment Routing 96 ECMP - Equal Cost Multi Paths 97 MPLS - Multi Protocol Label Switching 99 SID - Segment Identifier 101 3. Entropy Labels for source routed stacked tunnels 103 Stacked tunnels have several use-cases, one of which is service 104 chaining [I-D.filsfils-rtgwg-segment-routing-use-cases]. Consider a 105 service-chaining network in Figure 1. The source LSR S wants to send 106 traffic to destination LSR D. This traffic is required to go through 107 service nodes S1 and S2 to produce the service chain S-S1-S2-D. 108 Segment Routing can be used to achieve this. Load balancing is 109 required across the parallel links between P1 and S1. Load balancing 110 is also required between the ECMP paths from S1 to S2, S1-P1-P2-P3-S2 111 and S1-P1-P2-P4-S2. The source LSR wants the intermediate LSRs P1 112 and P2 to take local load balancing decisions and does not specify 113 the Segment Identifiers (SIDs) of specific interfaces. Entropy 114 labels should be used to achieve the desired load balancing. Two 115 possible ways to use the entropy labels and their associated 116 tradeoffs are discussed below. We denote SN to be the node segment 117 identifier (SID) of LSR N and SN{L1,L2,...} to denote the SID of the 118 adjacency set for links {L1,L2,...} of LSR N and S-N to denote the 119 SID for a service at service node N. The label stack that the source 120 LSR S uses for the service chain can be or 121 . The issues discussed in this 122 document are equally applicable to both of these options. 124 +-----+ +-----+ 125 | S1 | +------| P3 |------+ 126 +-----+ | +-----+ | 127 L1| |L2 | | 128 +-----+ +-----+ +-----+ +-----+ 129 | S |-----| P1 |-----| P2 | | S2 | 130 +-----+ +-----+ +-----+ +-----+ 131 | | 132 | +-----+ | 133 +------| P4 |------+ 134 +-----+ 135 | 136 +-----+ 137 | D | 138 +-----+ 140 S=Source LSR, D=Destination LSR, S1,S2=service-nodes, L1,L2=links, 141 P1,P2,P3,P4=Transit LSRs 143 Figure 1: Service chaining use-case 145 3.1. Single EL at the bottom of the stack of tunnels 147 In this option a single EL is used for the entire label stack. The 148 source LSR S encodes the entropy label (EL) below the labels of all 149 the stacked tunnels. In Figure 1 label stack at LSR S would look 150 like . Note that the notation in [RFC6790] is used to 152 describe the label stack. An issue with this approach is that as the 153 label stack grows due an increase in the number of SIDs, the EL 154 correspondingly goes deeper in the label stack. As a result, 155 intermediate LSRs (such as P1) that have to walk the label stack at 156 least until the EL to perform load balancing decisions have to access 157 a larger number of bytes in the packet header when making forwarding 158 decisions. A network design using this approach, should ensure that 159 all intermediate LSRs have the capability to traverse the maximum 160 label stack depth in order to do effective load balancing. The use- 161 case for which the tunnel stacking is applied would determine the 162 maximum label stack depth. 164 3.2. An EL per tunnel in the stack 166 In this option each tunnel in the stack can be given its own EL. The 167 source LSR pushes an before pushing a tunnel label when 168 load balancing is required to direct traffic on that tunnel. For the 169 same Figure 1 above, the source LSR S encoded label stack would be 170 where all 171 the ELs would typically have the same value. Accessing the EL at an 172 intermediate LSR is independent of the depth of the label stack and 173 hence independent of the specific use-case to which the stacked 174 tunnels are applied. A drawback is that the depth of the label stack 175 grows significantly, almost 3 times as the number of labels in the 176 label stack. The network design should ensure that source LSRs 177 should have the capability to push such a deep label stack. Also, 178 the bandwidth overhead and potential MTU issues of deep label stacks 179 should be accounted for in the network design. 181 3.3. A re-usable EL for a stack of tunnels 183 In this option an LSR that terminates a tunnel re-uses the EL of the 184 terminated tunnel for the next inner tunnel. It does this by storing 185 the EL from the outer tunnel when that tunnel is terminated and re- 186 inserting it below the next inner tunnel label during the label swap 187 operation. The LSR that stacks tunnels SHOULD insert an EL below the 188 outermost tunnel. It SHOULD NOT insert ELs for any inner tunnels. 189 For the same Figure 1 above, the source LSR S encoded label stack 190 would be . At P1 the 191 outgoing label stack would be after it 192 has load balanced to one of the links L1 or L2. At S1 the outgoing 193 label stack would be . At P2 the outgoing label 194 stack would be and it would load balance to one of 195 the nexthop LSRs P3 or P4. Accessing the EL at an intermediate LSR 196 is independent of the depth of the label stack and hence independent 197 of the specific use-case to which the stacked tunnels are applied. 199 3.4. ELs at readable label stack depths 201 In this option the source LSR inserts ELs for tunnels in the label 202 stack at depths such that each LSR along the path that must load 203 balance is able to access at least one EL. Note that the source LSR 204 may have to insert multiple ELs in the label stack at different 205 depths for this to work since intermediate LSRs may have differing 206 capabilities in accessing the depth of a label stack. The label 207 stack depth access value of intermediate LSRs must be known to create 208 such a label stack. How this value is determined is outside the 209 scope of this document. This value can be advertised using a 210 protocol such as an IGP. Details of this will follow in subsequent 211 versions if this option is found to be worth pursuing. For the same 212 Figure 1 above, if LSR P1 needs to have the EL within a depth of 4, 213 then the source LSR S encoded label stack would be where all the ELs would 215 typically have the same value. 217 4. Acknowledgements 219 The authors would like to thank Rob Shakir and TBD for their 220 comments. 222 5. IANA Considerations 224 This memo includes no request to IANA. 226 6. Security Considerations 228 7. References 230 7.1. Normative References 232 [I-D.filsfils-rtgwg-segment-routing-use-cases] 233 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 234 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 235 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 236 "Segment Routing Use Cases", draft-filsfils-rtgwg-segment- 237 routing-use-cases-01 (work in progress), July 2013. 239 [I-D.filsfils-rtgwg-segment-routing] 240 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 241 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 242 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 243 "Segment Routing Architecture", draft-filsfils-rtgwg- 244 segment-routing-00 (work in progress), June 2013. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 250 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 251 RFC 6790, November 2012. 253 7.2. Informative References 255 [I-D.previdi-isis-segment-routing-extensions] 256 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and 257 S. Litkowski, "IS-IS Extensions for Segment Routing", 258 draft-previdi-isis-segment-routing-extensions-02 (work in 259 progress), July 2013. 261 [I-D.psenak-ospf-segment-routing-extensions] 262 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., and R. 263 Shakir, "OSPF Extensions for Segment Routing", draft- 264 psenak-ospf-segment-routing-extensions-02 (work in 265 progress), July 2013. 267 Authors' Addresses 269 Sriganesh Kini (editor) 270 Ericsson 272 Email: sriganesh.kini@ericsson.com 274 Kireeti Kompella 275 Juniper 277 Email: kireeti@juniper.net 279 Siva Sivabalan 280 Cisco 282 Email: msiva@cisco.com