Re: [mpls] [Technical Errata Reported] RFC5960 (2533)

Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk> Thu, 30 September 2010 00:18 UTC

Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D593A6A8B for <mpls@core3.amsl.com>; Wed, 29 Sep 2010 17:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.251
X-Spam-Level:
X-Spam-Status: No, score=-103.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sujWOe53Dful for <mpls@core3.amsl.com>; Wed, 29 Sep 2010 17:18:07 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 794CF3A6A0C for <mpls@ietf.org>; Wed, 29 Sep 2010 17:18:06 -0700 (PDT)
Received: from host86-170-51-184.range86-170.btcentralplus.com ([86.170.51.184] helo=unknown-00-22-43-25-f9-66.home) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1P16rJ-00042e-53; Thu, 30 Sep 2010 01:18:49 +0100
References: <20100929173931.1B2F0E06C4@rfc-editor.org>
In-Reply-To: <20100929173931.1B2F0E06C4@rfc-editor.org>
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <38C5A032-A518-4CFA-B387-CE6F9BF01F6C@niven-jenkins.co.uk>
Content-Transfer-Encoding: quoted-printable
From: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Thu, 30 Sep 2010 01:18:42 +0100
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.1078)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: italo.busi@alcatel-lucent.com, mpls@ietf.org, danfrost@cisco.com, adrian.farrel@huawei.com, stbryant@cisco.com
Subject: Re: [mpls] [Technical Errata Reported] RFC5960 (2533)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Thu, 30 Sep 2010 00:18:09 -0000

While the intent of reported errata is technically correct I'm somewhat torn between whether I think it should be rejected, or whether I don't care.

My thinking is:

The errata is technically correct because a corner case does exist where a section layer that doesn't support higher layer protocol multiplexing can still be used to support MPLS-TP in some scenarios.

I don't like the proposed replacement text because the original text is placing a requirement on the section layer technology and I think it is reasonable to say "if you want your section layer to work with MPLS-TP it MUST do/support X", however I don't think it's reasonable to say "if you want your section layer to work with MPLS-TP it MAY have to do X" (which is essentially the change the proposed text makes) because it leaves it unclear as to what is actually required from the section layer which practically reduces to section layers having to support X anyway so it becomes a (implicit) MUST in any case.

Furthermore the original text only states that a section layer MUST have a means of identifying the type of payload. If a section layer does not support multiplexing then it has an implicit means of identifying the payload by the interface over which the payload arrived and therefore it meets the requirement as stated by the original text.

Ben


On 29 Sep 2010, at 18:39, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5960,
> "MPLS Transport Profile Data Plane Architecture".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5960&eid=2533
> 
> --------------------------------------
> Type: Technical
> Reported by: Italo Busi <italo.busi@alcatel-lucent.com>
> 
> Section: 3.2
> 
> Original Text
> -------------
>   A section MUST provide a means of identifying the type of payload it
>   carries.
> 
> Corrected Text
> --------------
>   A section MAY be required to provide a mechanism for multiplexing MPLS
>   with other protocols.  
> 
> 
> Notes
> -----
> This change is intended to clarify that providing a multiplexing capability for a section layer is optional.
> 
> See https://datatracker.ietf.org/liaison/916/
> 
> Instructions:
> -------------
> This errata 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 (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5960 (draft-ietf-mpls-tp-data-plane-04)
> --------------------------------------
> Title               : MPLS Transport Profile Data Plane Architecture
> Publication Date    : August 2010
> Author(s)           : D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed.
> Category            : PROPOSED STANDARD
> Source              : Multiprotocol Label Switching
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls