Subject: Protocol Action: 'Avoiding Equal Cost Multipath Treatment in MPLS Networks' to BCP

From: The IESG <[email-masked]>
Date: Sun, 18 Mar 2007 06:01:33 -0400

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce