idnits 2.17.1 draft-bryant-pals-ethernet-cw-00.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 (Using the creation date from RFC4448, updated by this document, for RFC5378 checks: 2002-09-04) -- 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 (May 25, 2017) is 2520 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PALS Working Group S. Bryant 3 Internet-Draft A. Malis 4 Updates: 4448 (if approved) Huawei 5 Intended status: Standards Track I. Bagdonas 6 Expires: November 26, 2017 Equinix 7 May 25, 2017 9 Use of Ethernet Control Word RECOMMENDED 10 draft-bryant-pals-ethernet-cw-00 12 Abstract 14 The pseudowire (PW) encapsulation of Ethernet, as defined in RFC4448, 15 specifies that the use of the control word (CW) is optional. In the 16 absence of the CW an Ethernet pseudowire packet can be misidentified 17 as an IP packet by a label switching router (LSR). This in turn may 18 lead to the selection of the wrong equal-cost-multi-path (ECMP) path 19 for the packet, leading in turn to the mis-ordering of packets. This 20 problem has become more serious due to the deployment of equipment 21 with Ethernet MAC addresses that start with 0x4 or 0x6. The use of 22 the Ethernet PW CW addresses this problem. This document recommends 23 the use of the Ethernet pseudowire control word in all but 24 exceptional circumstances. 26 This document updates RFC4448. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 26, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 64 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Equal Cost Multi-path (ECMP) . . . . . . . . . . . . . . . . 5 67 6. Differential Treatment of Traffic Flows . . . . . . . . . . . 6 68 7. Mitigations . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Operational Considerations . . . . . . . . . . . . . . . . . 6 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 12.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 The pseudowire(PW) encapsulation of Ethernet, as defined in RFC4448, 81 specifies that the use of the control word (CW) is optional. It is 82 common for label switching routers (LSRs) to search past the end of 83 the label stack to determine whether the payload is an IP packet, and 84 if the payload is an IP packet, to select the next hop based of the 85 so called "five-tuple" (IP source address, IP destination address, 86 protocol/next-header, transport layer source port and transport layer 87 destination port). In the absence of a PW CW an Ethernet pseudowire 88 packet can be misidentified as an IP packet by a label switching 89 router (LSR) selecting the ECMP path based on the five-tuple. This 90 in turn may lead to the selection of the wrong equal-cost-multi-path 91 (ECMP) path for the packet, leading in turn to the mis-ordering of 92 packets. Further discussion of this topic is published in [RFC4928]. 94 Flow misordering can also happen in a single path scenario when 95 traffic classification and differential forwarding treatment 96 mechanisms Section 6 are in use. 98 This problem has become more serious due to the deployment of 99 equipment with Ethernet MAC addresses that start with 0x4 or 0x6. 100 The use of the Ethernet PW CW addresses this problem. 102 This document recommends the use of the Ethernet pseudowire control 103 word in all but exceptional circumstances. 105 2. Specification of Requirements 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 3. Background 113 Ethernet pseudowire encapsulation is specified in [RFC4448]. In 114 particular the reader is drawn to section 4.6, part of which is 115 quoted below for the convenience of the reader: 117 "The control word defined in this section is based on the Generic 118 PW MPLS Control Word as defined in [RFC4385]. It provides the 119 ability to sequence individual frames on the PW, avoidance of 120 equal-cost multiple-path load-balancing (ECMP) [RFC2992], and 121 Operations and Management (OAM) mechanisms including VCCV 122 [RFC5085]. 124 "[RFC4385] states, "If a PW is sensitive to packet misordering 125 and is being carried over an MPLS PSN that uses the contents 126 of the MPLS payload to select the ECMP path, it MUST employ a 127 mechanism which prevents packet misordering." This is necessary 128 because ECMP implementations may examine the first nibble after 129 the MPLS label stack to determine whether the labeled packet 130 is IP or not. Thus, if the source MAC address of an Ethernet 131 frame carried over the PW without a control word present begins 132 with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 133 packet. This could, depending on the configuration and 134 topology of the MPLS network, lead to a situation where all 135 packets for a given PW do not follow the same path. This may 136 increase out-of-order frames on a given PW, or cause OAM packets 137 to follow a different path than actual traffic (see 138 Section 4.4.3, "Frame Ordering"). 140 "The features that the control word provides may not be needed 141 for a given Ethernet PW. For example, ECMP may not be present 142 or active on a given MPLS network, strict frame sequencing may 143 not be required, etc. If this is the case, the control word 144 provides little value and is therefore optional. Early Ethernet 145 PW implementations have been deployed that do not include a 146 control word or the ability to process one if present. To 147 aid in backwards compatibility, future implementations MUST 148 be able to send and receive frames without the control word 149 present." 151 At the time when pseudowires were first deployed, some equipment of 152 commercial significance was unable to process the Ethernet Control 153 Word. In addition, at that time it was considered that no Ethernet 154 MAC address had been issued by the IEEE Registration Authority 155 Committee (RAC) that starts with 0x4 or 0x6, and thus it was thought 156 to be safe to deploy Ethernet PWs without the CW. 158 Since that time the RAC has issued Ethernet MAC addresses start with 159 0x4 or 0x6 and thus the assumption that in practical networks there 160 would be no confusion between an Ethernet PW packet without the CW 161 and an IP packet is no longer correct. 163 Possibly through the use of unauthorized Ethernet MAC addresses, this 164 assumption has been unsafe for a while, leading some equipment 165 vendors to implement more complex, proprietary, methods to 166 discriminate between Ethernet PW packets and IP packets. Such 167 mechanisms rely on the heuristics of examining the transit packets in 168 trying to find out the exact payload type of the packet and cannot be 169 reliable due to the random nature of the payload carried within such 170 packets. 172 A recent posting on the Nanog email list has highlighted this 173 problem: 175 https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html 177 RFC EDITOR Please delete this paragraph. 178 Kramdown does not include references when they are only found in 179 literal text so I include them here: [RFC4385] [RFC2992] [RFC5085] as 180 a fixup. 182 4. Recommendation 184 The ambiguity between an MPLS payload that is a Ethernet PW and one 185 that is an IP packet is resolved when the Ethernet PW control word is 186 used. This document updates RFC4448 [RFC4448] to state that where 187 both both the ingress PE and the egress PE support the Ethernet 188 pseudowire control word, then the CW MUST be used. 190 5. Equal Cost Multi-path (ECMP) 192 Where the volume of traffic on an Ethernet PW is such that ECMP is 193 required then one of two methods may be used: 195 o Flow-Aware Transport (FAT) of Pseudowires over an MPLS Packet 196 Switched Network specified in [RFC6391], or 198 o LSP entropy labels specified [RFC6790] 200 RFC6391 works by increasing the entropy of the bottom of stack label. 201 It requires that both the ingress and egress provider edge (PE)s 202 support this feature. It also requires that sufficient LSRs on the 203 LSP between the ingress and egress PE be able to select an 204 ECMP path on an MPLS packet with the resultant stack depth. 206 RFC6790 works by including an entropy value in the LSP part of the 207 label stack. This requires that the Ingress and Egress PEs support 208 the insertion and removal of the entropy label (EL) and the entropy 209 label indicator, and that sufficient LSRs on the LSP are able to 210 preform ECMP based on the EL. 212 In both cases there considerations in getting Operations, 213 Administration, and Maintenance (OAM) packets to follow the same path 214 as a data packet. This is described in detail section 7 of 215 [RFC6391], and section 6 of RFC6790. However in both cases the 216 situation is improved compared to the ECMP behavior in the case where 217 the Ethernet PW CW was not used, since there is currently no known 218 method of getting a PW OAM packet to follow the same path as a PW 219 data packet subjected to ECMP based on the five tuple of the IP 220 payload. 222 6. Differential Treatment of Traffic Flows 224 A description of this will be provided in a future version. 226 7. Mitigations 228 Where it is not possible to use the Ethernet PW CW, the effects of 229 ECMP can be disabled by carrying the PW over a traffic engineered 230 path that does not subject the payload to load balancing (for example 231 [RFC3209]. However such paths may be subjected to link bundle load 232 balancing and of course the single LSP has to carry the full PW load. 234 8. Operational Considerations 236 CW presence on the PW is controlled by the configuration and may be 237 subject to default operational mode of not being enabled. Care needs 238 to be taken to ensure that software that implements this 239 recommendation does not depend on existing configuration setting that 240 prevents the use of control word. It is recommended that platform 241 software emits a rate limited message indicating that CW can be used 242 but is disabled due to existing configuration. 244 9. Security Considerations 246 This document expresses a preference for one existing and widely 247 deployed Ethernet PW encapsulation over another. These methods have 248 identical security considerations, which are discussed in [RFC4448]. 249 This document introduces no additional security issues. 251 10. IANA Considerations 253 This document makes no IANA requests. 255 11. Acknowledgements 257 The authors thank Job Snijders for drawing attention to this problem. 259 12. References 261 12.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 269 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 270 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 271 February 2006, . 273 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 274 "Encapsulation Methods for Transport of Ethernet over MPLS 275 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 276 . 278 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 279 Cost Multipath Treatment in MPLS Networks", BCP 128, 280 RFC 4928, DOI 10.17487/RFC4928, June 2007, 281 . 283 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 284 Regan, J., and S. Amante, "Flow-Aware Transport of 285 Pseudowires over an MPLS Packet Switched Network", 286 RFC 6391, DOI 10.17487/RFC6391, November 2011, 287 . 289 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 290 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 291 RFC 6790, DOI 10.17487/RFC6790, November 2012, 292 . 294 12.2. Informative References 296 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 297 Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, 298 . 300 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 301 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 302 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 303 . 305 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 306 Circuit Connectivity Verification (VCCV): A Control 307 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 308 December 2007, . 310 Authors' Addresses 312 Stewart Bryant 313 Huawei 315 Email: stewart.bryant@gmail.com 317 Andrew G Malis 318 Huawei 320 Email: agmalis@gmail.com 322 Ignas Bagdonas 323 Equinix 325 Email: ibagdona.ietf@gmail.com>