idnits 2.17.1 draft-ietf-mpls-ecmp-bcp-01.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. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. 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. == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) 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.) ** 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 2005) is 6858 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: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 2006 5 Stewart Bryant 6 Cisco Systems, Inc. 8 Loa Andersson 9 Acreo 11 July 2005 13 Avoiding Equal Cost Multipath Treatment in MPLS Networks 15 draft-ietf-mpls-ecmp-bcp-01.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 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 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document describes the Equal Cost Multipath (ECMP) behavior 43 of currently deployed MPLS networks and makes best practice 44 recommendations for anyone defining an application to run over an 45 MPLS network and wishes to avoid such treatment. 47 Contents 49 1 Introduction .............................................. 3 50 1.1 Terminology ............................................... 3 51 2 Current EMCP Practices .................................... 3 52 3 Recommendations for Avoiding ECMP Treatment ............... 5 53 4 Security Considerations ................................... 6 54 5 References ................................................ 6 55 5.1 Normative References ...................................... 6 56 6 Authors' Addresses ........................................ 6 58 1. Introduction 60 This document describes the Equal Cost Multipath (ECMP) behavior of 61 currently deployed MPLS networks and makes best practice recommenda- 62 tions for anyone defining an application to run over an MPLS network 63 and wishes to avoid such treatment. While disabling ECMP behavior is 64 an option open to most operators, few (if any) have chosen to do so. 65 Thus ECMP behavior is a reality that must be reckoned with. 67 1.1. Terminology 69 ECMP Equal Cost Multipath 71 FEC Forwarding Equivalence Class 73 IP ECMP A forwarding behavior in which the selection of the 74 next-hop between equal cost routes is based on the 75 header(s) of an IP packet 77 Label ECMP A forwarding behavior in which the selection of the 78 next-hop between equal cost routes is based on the 79 label stack of an MPLS packet 81 LSP Label Switched Path 83 LSR Label Switching Router 85 2. Current EMCP Practices 87 The MPLS label stack and Forwarding Equivalence Classes are defined 88 in [RFC3031]. The MPLS label stack does not carry a Protocol Identi- 89 fier. Instead the payload of an MPLS packet is identified by the 90 Forwarding Equivalence Class (FEC) of the bottom most label. Thus it 91 is not possible to know the payload type if one does not know the 92 label binding for the bottom most label. Since an LSR which is pro- 93 cessing a label stack need only know the binding for the label(s) it 94 must process, it is very often the case that LSRs along an LSP are 95 unable to determine the payload type of the carried contents. 97 As a means of potentially reducing delay and congestion, IP networks 98 have taken advantage of multiple paths through a network by splitting 99 traffic flows across those paths. The general name for this practice 100 is Equal Cost Multipath or ECMP. In general this is done by hashing 101 on various fields on the IP or contained headers. In practice, 102 within a network core, the hashing in based mainly or exclusively on 103 the IP source and destination addresses. The reason for splitting 104 aggregated flows in this manner is to minimize the re-ordering of 105 packets belonging to individual flows contained within the aggregated 106 flow. Within this document we use the term IP ECMP for this type of 107 forwarding algorithm. 109 In the early days of MPLS, the payload was almost exclusively IP. 110 Even today the overwhelming majority of carried traffic remains IP. 111 Providers of MPLS equipment sought to continue this IP ECMP behavior. 112 As shown above, it is not possible to know whether the payload of an 113 MPLS packet is IP at every place where IP ECMP needs to be performed. 114 Thus vendors have taken the liberty of guessing what the payload is. 115 By inspecting the first nibble beyond the label stack, it can be 116 inferred that a packet is not IPv4 or IPv6 if the value of the nibble 117 (where the IP version number would be found) is not 0x4 or 0x6 118 respectively. Most deployed LSRs will treat a packet whose first 119 nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP 120 ECMP. 122 A consequence of this is that any application which defines a FEC 123 which does not take measures to prevent the values 0x4 and 0x6 from 124 occurring in the first nibble of the payload may be subject to IP 125 ECMP and thus having their flows take multiple paths and arriving 126 with considerable jitter and possibly out of order. While none of 127 this is in violation of the basic service offering of IP, it is 128 detrimental to the performance of various classes of applications. 129 It also complicates the measurement, monitoring and tracing of those 130 flows. 132 New MPLS payload types are emerging such as those specified by the 133 IETF PWE3 and AVT working groups. These payloads are not IP and, if 134 specified without constraint might be mistaken for IP. 136 It must also be noted that LSRs which correctly identify a payload as 137 not being IP, may still need to load-share this traffic across multi- 138 ple equal-cost paths. In this case a LABEL ECMP algorithm is 139 employed, where a hash is computed on all or part(s) of the label 140 stack. Any reserved label, no matter where it is located in the 141 stack, may be included in the computation for load balancing. Modi- 142 fication of the label stack between packets of a single flow could 143 result in re-ordering that flow. That is, were an explicit null or a 144 router-alert label to be added to a packet, that packet could take a 145 different path through the network. 147 Note that for some applications, being mistaken for IPv4 may not be 148 detrimental. The trivial case where the payload behind the top label 149 is a packet belonging to an MPLS IPv4 VPN. Here the real payload is 150 IP and most (if not all) deployed equipment will locate the end of 151 the label stack and correctly perform IP ECMP. 153 A less obvious case is when the packets of a given flow happen to 154 have constant values in the fields upon which IP ECMP would be per- 155 formed. For example if an ethernet frame immediately follows the 156 label and the LSR does not do ECMP on IPv6, then either the first 157 nibble will be 0x4 or it will be something else. If the nibble is 158 not 0x4 then no IP ECMP is performed, but Label ECMP may be per- 159 formed. If it is 0x4, then the constant values of the MAC addresses 160 overlay the fields that would be occupied by the source and destina- 161 tion addresses of an IP header. 163 3. Recommendations for Avoiding ECMP Treatment 165 The field in the figure below tagged "Application Label" is a label 166 of the FEC Type used/defined by the application. It is the bottom 167 most label in the label stack. As such its FEC Type defines the pay- 168 load which follows. Anyone defining an application to be transported 169 over MPLS is free to define new FEC Types and the format of the pay- 170 load which will be carried. 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Label | Exp |0| TTL | MPLS 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 . . . . . 178 . . . . . 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Label | Exp |0| TTL | Label 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Application Label | Exp |1| TTL | Stack 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |1st Nbl| | Payload 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 In order to avoid IP ECMP treatment it is necessary that an applica- 188 tion take precautions to not be mistaken as IP by deployed equipment 189 that snoops on the presumed location of the IP Version field. Thus, 190 at a minimum, the chosen format must disallow the values 0x4 and 0x6 191 in the first nibble of their payload. 193 It is strongly recommended, however, that applications restrict the 194 first nibble values to 0x0 and 0x1. This will ensure that that their 195 traffic flows will not be affected if some future routing equipment 196 does similar snooping on some future version of IP. 198 4. Security Considerations 200 This memo documents current practices. As such it creates no new 201 security considerations. 203 5. References 205 5.1. Normative References 207 [RFC3031] Rosen, E. et al., "Multiprotocol Label Switching 208 Architecture", January 2001. 210 6. Authors' Addresses 212 Loa Andersson 213 Acreo 215 Email: loa@pi.se 217 Stewart Bryant 218 Cisco Systems 219 250, Longwater, 220 Green Park, 221 Reading, RG2 6GB, UK 223 Email: stbryant@cisco.com 225 George Swallow 226 Cisco Systems, Inc. 227 1414 Massachusetts Ave 228 Boxborough, MA 01719 230 Email: swallow@cisco.com 232 Copyright Notice 234 Copyright (C) The Internet Society (2005). This document is subject 235 to the rights, licenses and restrictions contained in BCP 78, and 236 except as set forth therein, the authors retain all their rights. 238 Expiration Date 240 January 2006 242 Disclaimer of Validity 244 This document and the information contained herein are provided on an 245 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 246 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 247 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 248 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 249 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 250 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.