The IESG has approved the following document: - 'Avoiding Equal Cost Multipath Treatment in MPLS Networks ' <draft-ietf-mpls-ecmp-bcp-03.txt> as a BCP This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ecmp-bcp-03.txt Technical Summary This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. Working Group Summary The WG had consensus on progressing this document. Protocol Quality The document has been reviewed by Alex Zinin and by Ross Callon for the IESG. Among other things The document describes mechanisms implemented by MPLS router vendors and deployed in real-life networks. The document has also been updated based on comments received during IESG review. Note to RFC Editor The Abstract currently reads: This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. This should be replaced with: This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks even if future allocations of IP version numbers were made for some purpose. A minor nit in the third paragraph of section 2: For packets that contain both a label stack and an encapsulated IPv4 (or IPv6) packet, current implementations in some cases may hash on any combination of labels and IPv4 (or IPv6) source and destination labels. The word "labels" at the end of this paragraph should be "addresses". Also, the document was created with hyphenation turned on. I am assuming that this should probably be turned off. The second to last paragraph of section 3 currently reads: It is strongly recommended, however, that applications restrict the first nibble values to 0x0 and 0x1. This will ensure that that their traffic flows will not be affected if some future routing equipment does similar snooping on some future version of IP. This should be replaced with the following two paragraphs: It is REQUIRED, however, that applications that require in-order packet delivery restrict the first nibble values to 0x0 and 0x1. This will ensure that their traffic flows will not be affected if some future routing equipment does similar snooping on some future version(s) of IP. This behavior implies that if in the future an IP version is defined with a version number of 0x0 or 0x1, then equipment complying with this BCP would be unable to look past one or more MPLS headers, and loadsplit traffic from a single LSP across multiple paths based on a hash of specific fields in the IPv0 or IPv1 headers. That is, IP traffic employing these version numbers would be safe from disturbances caused by inappropriate loadsplitting, but would also not be able to get the performance benefits. Finally, we need a IANA Considerations section as follows: X. IANA Considerations This document requests the marking of the value 0x1 in the IP protocol version number space as "Reserved" (currently marked as "Unassigned"). In addition, a reference to this document should be placed to both values 0x0 and 0x1. Note that this document does not in any way change the policies regarding the allocation of version numbers, including the possible use of the reserved numbers for some future purpose. IANA Note We request that the IP version number of "1" should be marked as "reserved" rather than "unassigned". Also, the IP version numbers of 0 and 1 should reference this document in addition to the existing reference. Specifically, looking at: http://www.iana.org/assignments/version-numbers we see the current text: Assigned Internet Version Numbers Decimal Keyword Version References ------- ------- ------- ---------- 0 Reserved [JBP] 1-3 Unassigned [JBP] This would change to: Assigned Internet Version Numbers Decimal Keyword Version References ------- ------- ------- ---------- 0-1 Reserved [JBP],[new rfc] 2-3 Unassigned [JBP] _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
