IETF Logo Mail Archive

[mpls] [Technical Errata Reported] RFC4928 (5396)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 18 June 2018 09:37 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51DD1277C8 for <mpls@ietfa.amsl.com>; Mon, 18 Jun 2018 02:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h6RcbFQTdI6 for <mpls@ietfa.amsl.com>; Mon, 18 Jun 2018 02:37:20 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89988130DC7 for <mpls@ietf.org>; Mon, 18 Jun 2018 02:37:20 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id B959CB80978; Mon, 18 Jun 2018 02:37:15 -0700 (PDT)
To: stbryant@cisco.com, swallow@cisco.com, loa@pi.se, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, loa@pi.nu, n.leymann@telekom.de
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: jsharma@ciena.com, mpls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20180618093715.B959CB80978@rfc-editor.org>
Date: Mon, 18 Jun 2018 02:37:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/BpmEr-_Vb3DrTe38qnpAVNqheL8>
Subject: [mpls] [Technical Errata Reported] RFC4928 (5396)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2018 09:37:24 -0000

The following errata report has been submitted for RFC4928,
"Avoiding Equal Cost Multipath Treatment in MPLS Networks".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5396

--------------------------------------
Type: Technical
Reported by: Jitendra Kumar Sharma <jsharma@ciena.com>

Section: Section 2

Original Text
-------------
   A less obvious case is when the packets of a given flow happen to
   have constant values in the fields upon which IP ECMP would be
   performed.  For example, if an Ethernet frame immediately follows the
   label and the LSR does ECMP on IPv4, but does not do ECMP on IPv6,
   then either the first nibble will be 0x4, or it will be something
   else.  If the nibble is not 0x4 then no IP ECMP is performed, but
   Label ECMP may be performed.  If it is 0x4, then the constant values
   of the MAC addresses overlay the fields that would have been occupied
   by the source and destination addresses of an IP header.  In this
   case, the input to the ECMP algorithm would be a constant value and
   thus the algorithm would always return the same result.

Corrected Text
--------------
<This paragraph should be removed>

Notes
-----
The example stated here seems incorrect. It talks about an L2VPN case where Ethernet frame starts immediately after the last label in the stack. But had it been an IP packet instead, the same initial 12 bytes, which is the place for MAC addresses in an Ethernet Frame, would not be the place of IP addresses, as IP addresses are placed at the end of 20-byte IP header (not start). Hence it would still be subjected to ECMP if precautions (as recommended in this RFC) are not been followed.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4928 (draft-ietf-mpls-ecmp-bcp-03)
--------------------------------------
Title               : Avoiding Equal Cost Multipath Treatment in MPLS Networks
Publication Date    : June 2007
Author(s)           : G. Swallow, S. Bryant, L. Andersson
Category            : BEST CURRENT PRACTICE
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

v2.23.0 | Report a Bug | By Email