[mpls] Progressing Resolution of Erratum 2533 (RFC 5960)

Adrian Farrel <Adrian.Farrel@huawei.com> Wed, 10 November 2010 07:38 UTC

Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 664AE3A6802; Tue, 9 Nov 2010 23:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8NBZmCHMoLu6; Tue, 9 Nov 2010 23:38:11 -0800 (PST)
Received: from usaga03-in.huawei.com (usaga03-in.huawei.com []) by core3.amsl.com (Postfix) with ESMTP id 89D603A67C2; Tue, 9 Nov 2010 23:38:11 -0800 (PST)
Received: from huawei.com (usaga03-in []) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN00M6BRWDIA@usaga03-in.huawei.com>; Wed, 10 Nov 2010 01:38:38 -0600 (CST)
Received: from 950129200 (dhcp-731c.meeting.ietf.org []) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBN00MZIRWBBV@usaga03-in.huawei.com>; Wed, 10 Nov 2010 01:38:37 -0600 (CST)
Date: Wed, 10 Nov 2010 07:38:36 +0000
From: Adrian Farrel <Adrian.Farrel@huawei.com>
To: ahmpls-tp@lists.itu.int, mpls@ietf.org, mpls-tp@ietf.org
Message-id: <0d0301cb80aa$4a9d75a0$dfd860e0$@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-gb
Content-transfer-encoding: 7bit
Thread-index: AcuAqkGWWLljIycMSaaDutg2dx6+Tw==
Subject: [mpls] Progressing Resolution of Erratum 2533 (RFC 5960)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian.Farrel@huawei.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 10 Nov 2010 07:38:12 -0000


Thank you for your input and suggestions on this topic.

To be clear, we are not attempting to reach consensus on what change to make,
but I am listening to your individual opinions.

In deciding what Erratum to post, I will select a form of words that clarifies
the published RFC text, but which does not make a technical change. I intend to
reflect the consensus of the IETF that was demonstrated by the publication of
this document.

The Erratum process is intended to correct typographic or rendition issues that
produce Editorial or Technical issues in the published text. The process is not
intended to make technical changes or fixes. Such issues should be handled by
revising the work through the IETF consensus process. draft-ietf-mpls-tp-uni-nni
is a good example of how that is done.

Now, with regard to this particular Erratum.

It seems to me that there are two separate concerns.

The first concern is about identification of payloads. This is needed for a
range of reasons, and is a firm requirement in the existing text (and, indeed in
the MPLS architecture). However, it is noted that the identification may be
explicit or implicit. The text also notes that the use of explicit
identification of payload is a facilitator for demultiplexing multiplexed

The second concern is whether there is a requirement to support payload
multiplexing. I do not believe there is any statement about the support for
multiplexing in RFC 5960. The only mention of the subject is in the filed
Erratum. It would be wrong to introduce any statement of requirement or
non-requirement through an Erratum.

So, I'm not hearing anything that persuades me that the Erratum should be
different from what I wrote. If folk want to establish a specific requirement
that multiplexing is not required, then they can go ahead and write  a draft. I
cannot speak for how the WG will greet such a draft.