idnits 2.17.1 draft-ietf-mpls-ecmp-bcp-00.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.5 on line 220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 244. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. 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 2004) is 7156 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: 6 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group George Swallow 3 Internet Draft Cisco Systems, Inc. 4 Category: Standards Track 5 Expiration Date: March 2005 6 Stewart Bryant 7 Cisco Systems, Inc. 9 Loa Andersson 10 Acreo 12 September 2004 14 Avoiding Equal Cost Multipath Treatment in MPLS Networks 16 draft-ietf-mpls-ecmp-bcp-00.txt 18 Status of this Memo 20 By submitting this Internet-Draft, the authors certify that any 21 applicable patent or other IPR claims of which we are aware have been 22 disclosed, and any of which we become aware will be disclosed, in 23 accordance with RFC 3668. 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 5 of RFC3667. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, 28 and its working groups. Note that other groups may also distribute 29 working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 47 This document describes the Equal Cost Multipath (ECMP) behavior 48 of currently deployed MPLS networks and makes best practice 49 recommendations for anyone defining an application to run over an 50 MPLS network and wishes to avoid such treatment. 52 Contents 54 1 Introduction ........................................... 3 55 2 Current EMCP Practices ................................. 3 56 3 Recommendations for Avoiding ECMP Treatment ............ 4 57 4 Security Considerations ................................ 5 58 5 References ............................................. 5 59 5.1 Normative References ................................... 5 60 6 Authors' Addresses ..................................... 6 61 7 Full Copyright and Intellectual Property Statements .... 6 63 1. Introduction 65 This document describes the Equal Cost Multipath (ECMP) behavior of 66 currently deployed MPLS networks and makes best practice 67 recommendations for anyone defining an application to run over an 68 MPLS network and wishes to avoid such treatment. While turning ECMP 69 off is an option open to most operators, few (if any) have chosen to 70 do so. Thus ECMP behavior is a reality that must be reckoned with. 72 2. Current EMCP Practices 74 The MPLS label stack and Fowarding Equivalence Classes are defined in 75 [RFC3031]. The MPLS label stack does not carry a Protocol 76 Identifier. Instead the payload of an MPLS packet is identified by 77 the Forwarding Equivalence Class (FEC) of the bottom most label. 78 Thus it is not possible to know the payload type if one does not know 79 the label binding for the bottom most label. Since an LSR which is 80 processing a label stack need only know the binding for the label(s) 81 it must process, it is very often the case that LSRs along an LSP are 82 unable to determine the payload type of the carried contents. 84 IP networks have taken advantage of multiple paths through a network 85 by splitting traffic flows across those paths. The general name for 86 this practice is Equal Cost Multipath or ECMP. In general this is 87 done by hashing on various fields on the IP or contained headers. In 88 practice, within a network core, the hashing in based mainly or 89 exclusively on the IP source and destination addresses. The reason 90 for splitting aggregated flows in this manner is to minimize the 91 mis-ordering of flows between individual IP hosts contained with in 92 the aggregated flow. 94 In the early days of MPLS, the payload was almost exclusively IP. 95 Even today the overwhelming majority of carried traffic remains IP. 96 Providers of MPLS equipment sought to continue this behavior. As 97 shown above, it is not possible to know whether the payload of an 98 MPLS packet is IP at every place where ECMP needs to be performed. 99 Thus vendors have taken the liberty of guessing what the payload is. 100 By inspecting the first nibble beyond the label stack, it can be 101 inferred that a packet is not IPv4 or IPv6 if the value of the nibble 102 (where the IP version number would be found) is not 0x4 or 0x6 103 respectively. Most deployed LSRs will treat a packet whose first 104 nibble is equal to 0x4 as if the payload were IPv4 for purposes of 105 ECMP. 107 A consequence of this is that any application which defines a FEC 108 which does not take measures to prevent the values 0x4 and 0x6 from 109 occurring in the first nibble of the payload may be subject to ECMP 110 and thus having their flows take multiple paths and arriving with 111 considerable jitter and possibly out of order. While none of this is 112 in violation of the basic service offering of IP, it is detrimental 113 to the performance of various classes of applications. It also 114 complicates the measurement, monitoring and tracing of those flows. 116 New MPLS payload types are emerging such as those specified by the 117 IETF PWE3 and AVT working groups. These payloads are not IP and, if 118 specified without constraint might be mistaken for IP. 120 Note that for some applications being mistaken for IPv4 may not be 121 detrimental. The trivial case where the payload behind the top label 122 is a packet belonging to an MPLS IPv4 VPN. Here the real payload is 123 IP and most (if not all) deployed equipment will locate the end of 124 the label stack and correctly perform ECMP. 126 A less obvious case is when the packets of a given flow happen to 127 have constant values in the fields upon which ECMP will be performed. 128 Consider an MPLS PSN that only does ECMP on IPv4 (i.e. not on IPv6). 129 If an ethernet frame immediately follows the label stack, then either 130 the first nibble will be 0x4 or it will be something else. If the 131 nibble is not 0x4 then no ECMP is performed. If it is 0x4, that is 132 it is mistaken for IPv4, then the constant values of the MAC 133 addresses overlay the fields that would be occupied by the source and 134 destination addresses of an IP header. Thus all packets of the flow 135 receive the same ECMP treatment. 137 3. Recommendations for Avoiding ECMP Treatment 139 The field in the figure below tagged "Application Label" is a label 140 of the FEC Type used/defined by the application. It is the bottom 141 most label in the label stack. As such its FEC Type defines the 142 payload which follows. Anyone defining an application to be 143 transported over MPLS is free to define new FEC Types and the format 144 of the payload which will be carried. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Label | Exp |0| TTL | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 . . . . . 152 . . . . . 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Label | Exp |0| TTL | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Application Label | Exp |1| TTL | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 |1st Nbl| | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: Label Stack and one Word of Payload 163 In order to avoid ECMP treatment it is necessary that an application 164 take precautions to not be mistaken as IP by deployed equipment that 165 snoops on the presumed location of the IP Version field. Thus, at a 166 minimum that the chosen format must disallow the values 0x4 and 0x6 167 in the first nibble of their payload. 169 It is strongly recommended, however, that applications restrict the 170 first nibble values to 0x0 and 0x1. This will ensure that that their 171 traffic flows will not be affected if some future routing equipment 172 does similar snooping on some future version of IP. 174 4. Security Considerations 176 This memo documents current practices. As such it creates no new 177 security considerations. 179 5. References 181 5.1. Normative References 183 [RFC3031] Rosen, E. et al., "Multiprotocol Label Swithing 184 Architecture", January 2001. 186 6. Authors' Addresses 188 Loa Andersson 189 Acreo 191 Email: loa@pi.se 193 Stewart Bryant 194 Cisco Systems 195 250, Longwater, 196 Green Park, 197 Reading, RG2 6GB, UK 199 Email: stbryant@cisco.com 201 George Swallow 202 Cisco Systems, Inc. 203 1414 Massachusetts Ave 204 Boxborough, MA 01719 206 Email: swallow@cisco.com 208 7. Full Copyright and Intellectual Property Statements 210 Copyright (C) The Internet Society (2004). This document is subject 211 to the rights, licenses and restrictions contained in BCP 78, and 212 except as set forth therein, the authors retain all their rights. 214 This document and the information contained herein are provided on an 215 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 216 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 217 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 218 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 219 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 220 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 222 Intellectual Property 224 The IETF takes no position regarding the validity or scope of any 225 Intellectual Property Rights or other rights that might be claimed to 226 pertain to the implementation or use of the technology described in 227 this document or the extent to which any license under such rights 228 might or might not be available; nor does it represent that it has 229 made any independent effort to identify any such rights. Information 230 on the procedures with respect to rights in RFC documents can be 231 found in BCP 78 and BCP 79. 233 Copies of IPR disclosures made to the IETF Secretariat and any 234 assurances of licenses to be made available, or the result of an 235 attempt made to obtain a general license or permission for the use of 236 such proprietary rights by implementers or users of this 237 specification can be obtained from the IETF on-line IPR repository at 238 http://www.ietf.org/ipr. 240 The IETF invites any interested party to bring to its attention any 241 copyrights, patents or patent applications, or other proprietary 242 rights that may cover technology that may be required to implement 243 this standard. Please address the information to the IETF at ietf- 244 ipr@ietf.org. 246 Acknowledgement 248 Funding for the RFC Editor function is currently provided by the 249 Internet Society.