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