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]