idnits 2.17.1 draft-ietf-mpls-ecmp-bcp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 271. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2005) is 6796 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group George Swallow 2 Internet Draft Cisco Systems, Inc. 3 Category: Standards Track 4 Expiration Date: March 2006 5 Stewart Bryant 6 Cisco Systems, Inc. 8 Loa Andersson 9 Acreo 11 September 2005 13 Avoiding Equal Cost Multipath Treatment in MPLS Networks 15 draft-ietf-mpls-ecmp-bcp-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 This document describes the Equal Cost Multipath (ECMP) behavior 42 of currently deployed MPLS networks and makes best practice 43 recommendations for anyone defining an application to run over an 44 MPLS network and wishes to avoid such treatment. 46 Contents 48 1 Introduction .............................................. 3 49 1.1 Terminology ............................................... 3 50 2 Current ECMP Practices .................................... 3 51 3 Recommendations for Avoiding ECMP Treatment ............... 5 52 4 Security Considerations ................................... 6 53 5 References ................................................ 6 54 5.1 Normative References ...................................... 6 55 6 Authors' Addresses ........................................ 6 57 1. Introduction 59 This document describes the Equal Cost Multipath (ECMP) behavior of 60 currently deployed MPLS networks and makes best practice recommenda- 61 tions for anyone defining an application to run over an MPLS network 62 and wishes to avoid such treatment. While disabling ECMP behavior is 63 an option open to most operators, few (if any) have chosen to do so. 64 Thus ECMP behavior is a reality that must be reckoned with. 66 1.1. Terminology 68 ECMP Equal Cost Multipath 70 FEC Forwarding Equivalence Class 72 IP ECMP A forwarding behavior in which the selection of the 73 next-hop between equal cost routes is based on the 74 header(s) of an IP packet 76 Label ECMP A forwarding behavior in which the selection of the 77 next-hop between equal cost routes is based on the 78 label stack of an MPLS packet 80 LSP Label Switched Path 82 LSR Label Switching Router 84 2. Current ECMP Practices 86 The MPLS label stack and Forwarding Equivalence Classes are defined 87 in [RFC3031]. The MPLS label stack does not carry a Protocol Identi- 88 fier. Instead the payload of an MPLS packet is identified by the 89 Forwarding Equivalence Class (FEC) of the bottom most label. Thus it 90 is not possible to know the payload type if one does not know the 91 label binding for the bottom most label. Since an LSR which is pro- 92 cessing a label stack need only know the binding for the label(s) it 93 must process, it is very often the case that LSRs along an LSP are 94 unable to determine the payload type of the carried contents. 96 As a means of potentially reducing delay and congestion, IP networks 97 have taken advantage of multiple paths through a network by splitting 98 traffic flows across those paths. The general name for this practice 99 is Equal Cost Multipath or ECMP. In general this is done by hashing 100 on various fields on the IP or contained headers. In practice, 101 within a network core, the hashing in based mainly or exclusively on 102 the IP source and destination addresses. The reason for splitting 103 aggregated flows in this manner is to minimize the re-ordering of 104 packets belonging to individual flows contained within the aggregated 105 flow. Within this document we use the term IP ECMP for this type of 106 forwarding algorithm. 108 In the early days of MPLS, the payload was almost exclusively IP. 109 Even today the overwhelming majority of carried traffic remains IP. 110 Providers of MPLS equipment sought to continue this IP ECMP behavior. 111 As shown above, it is not possible to know whether the payload of an 112 MPLS packet is IP at every place where IP ECMP needs to be performed. 113 Thus vendors have taken the liberty of guessing what the payload is. 114 By inspecting the first nibble beyond the label stack, it can be 115 inferred that a packet is not IPv4 or IPv6 if the value of the nibble 116 (where the IP version number would be found) is not 0x4 or 0x6 117 respectively. Most deployed LSRs will treat a packet whose first 118 nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP 119 ECMP. 121 A consequence of this is that any application which defines a FEC 122 which does not take measures to prevent the values 0x4 and 0x6 from 123 occurring in the first nibble of the payload may be subject to IP 124 ECMP and thus having their flows take multiple paths and arriving 125 with considerable jitter and possibly out of order. While none of 126 this is in violation of the basic service offering of IP, it is 127 detrimental to the performance of various classes of applications. 128 It also complicates the measurement, monitoring and tracing of those 129 flows. 131 New MPLS payload types are emerging such as those specified by the 132 IETF PWE3 and AVT working groups. These payloads are not IP and, if 133 specified without constraint might be mistaken for IP. 135 It must also be noted that LSRs which correctly identify a payload as 136 not being IP, most often will load-share traffic across multiple 137 equal-cost paths based on the label stack. Any reserved label, no 138 matter where it is located in the stack, may be included in the com- 139 putation for load balancing. Modification of the label stack between 140 packets of a single flow could result in re-ordering that flow. That 141 is, were an explicit null or a router-alert label to be added to a 142 packet, that packet could take a different path through the network. 144 Note that for some applications, being mistaken for IPv4 may not be 145 detrimental. The trivial case where the payload behind the top label 146 is a packet belonging to an MPLS IPv4 VPN. Here the real payload is 147 IP and most (if not all) deployed equipment will locate the end of 148 the label stack and correctly perform IP ECMP. 150 A less obvious case is when the packets of a given flow happen to 151 have constant values in the fields upon which IP ECMP would be per- 152 formed. For example if an ethernet frame immediately follows the 153 label and the LSR does not do ECMP on IPv6, then either the first 154 nibble will be 0x4 or it will be something else. If the nibble is 155 not 0x4 then no IP ECMP is performed, but Label ECMP may be per- 156 formed. If it is 0x4, then the constant values of the MAC addresses 157 overlay the fields that would be occupied by the source and destina- 158 tion addresses of an IP header. 160 3. Recommendations for Avoiding ECMP Treatment 162 We will use the term "Application Label" to refer to a label that has 163 been allocated with a FEC Type that is defined (or simply used) by an 164 application. Such labels necessarily appear at the bottom of the 165 label stack, that is, below labels associated with transporting the 166 packet across an MPLS network. The FEC Type of the Application label 167 defines the payload that follows. Anyone defining an application to 168 be transported over MPLS is free to define new FEC Types and the for- 169 mat of the payload which will be carried. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Label | Exp |0| TTL | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 . . . . . 177 . . . . . 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Label | Exp |0| TTL | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Application Label | Exp |1| TTL | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |1st Nbl| | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 In order to avoid IP ECMP treatment it is necessary that an applica- 187 tion take precautions to not be mistaken as IP by deployed equipment 188 that snoops on the presumed location of the IP Version field. Thus, 189 at a minimum, the chosen format must disallow the values 0x4 and 0x6 190 in the first nibble of their payload. 192 It is strongly recommended, however, that applications restrict the 193 first nibble values to 0x0 and 0x1. This will ensure that that their 194 traffic flows will not be affected if some future routing equipment 195 does similar snooping on some future version of IP. 197 4. Security Considerations 199 This memo documents current practices. As such it creates no new 200 security considerations. 202 5. References 204 5.1. Normative References 206 [RFC3031] Rosen, E. et al., "Multiprotocol Label Switching 207 Architecture", January 2001. 209 6. Authors' Addresses 211 Loa Andersson 212 Acreo 214 Email: loa@pi.se 216 Stewart Bryant 217 Cisco Systems 218 250, Longwater, 219 Green Park, 220 Reading, RG2 6GB, UK 222 Email: stbryant@cisco.com 224 George Swallow 225 Cisco Systems, Inc. 226 1414 Massachusetts Ave 227 Boxborough, MA 01719 229 Email: swallow@cisco.com 231 Copyright Notice 233 Copyright (C) The Internet Society (2005). This document is subject 234 to the rights, licenses and restrictions contained in BCP 78, and 235 except as set forth therein, the authors retain all their rights. 237 Expiration Date 239 March 2006 241 Disclaimer of Validity 243 This document and the information contained herein are provided on an 244 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 245 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 246 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 247 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 248 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 249 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 251 The IETF takes no position regarding the validity or scope of any 252 Intellectual Property Rights or other rights that might be claimed to 253 pertain to the implementation or use of the technology described in 254 this document or the extent to which any license under such rights 255 might or might not be available; nor does it represent that it has 256 made any independent effort to identify any such rights. Information 257 on the procedures with respect to rights in RFC documents can be 258 found in BCP 78 and BCP 79. 260 Copies of IPR disclosures made to the IETF Secretariat and any 261 assurances of licenses to be made available, or the result of an 262 attempt made to obtain a general license or permission for the use of 263 such proprietary rights by implementers or users of this 264 specification can be obtained from the IETF on-line IPR repository at 265 http://www.ietf.org/ipr. 267 The IETF invites any interested party to bring to its attention any 268 copyrights, patents or patent applications, or other proprietary 269 rights that may cover technology that may be required to implement 270 this standard. Please address the information to the IETF at 271 ietf-ipr@ietf.org.