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

Stewart Bryant <stbryant@cisco.com> Fri, 08 October 2010 17:09 UTC

Return-Path: <stbryant@cisco.com>
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 9C6EA3A68F9 for <mpls@core3.amsl.com>; Fri, 8 Oct 2010 10:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.591
X-Spam-Level:
X-Spam-Status: No, score=-110.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Q4xXsvi2f-aX for <mpls@core3.amsl.com>; Fri, 8 Oct 2010 10:09:56 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7690A3A68C1 for <mpls@ietf.org>; Fri, 8 Oct 2010 10:09:56 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.57,303,1283731200"; d="scan'208";a="168342240"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Oct 2010 17:11:01 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o98HB00v005800; Fri, 8 Oct 2010 17:11:00 GMT
Received: from dhcp-bdlk09-vlan301-data-64-103-105-102.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o98HAv814337; Fri, 8 Oct 2010 18:10:58 +0100 (BST)
Message-ID: <4CAF50A1.3050402@cisco.com>
Date: Fri, 08 Oct 2010 18:10:57 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: hhelvoort@chello.nl
References: <20100929173931.1B2F0E06C4@rfc-editor.org> <38C5A032-A518-4CFA-B387-CE6F9BF01F6C@niven-jenkins.co.uk> <4CADC554.6040307@cisco.com> <4CAED96F.1090301@chello.nl>
In-Reply-To: <4CAED96F.1090301@chello.nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mpls@ietf.org, italo.busi@alcatel-lucent.com, danfrost@cisco.com, adrian.farrel@huawei.com, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [mpls] [Technical Errata Reported] RFC5960 (2533)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: stbryant@cisco.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: Fri, 08 Oct 2010 17:09:57 -0000

  Hi Huub,

On 08/10/2010 09:42, Huub van Helvoort wrote:
> Hello Stweard,
>
> You replied:
>
>> Speaking as an author, my view is that the original text is correct, and
>> the correction is not needed.
>
> As an author you are are an expert in this topic.
> However, for the less experienced you knowledge, i.e.:
The preamble was to alert the reader that I was speaking as an 
individual contributor, and not as an AD. I.e. this is a technical 
comment and not a management comment.

>
>> It's a fundamental of the IP protocol suite (which includes MPLS)
> > that the parser knows what protocol to expect from the previous
> > header or if there is no previous header from an identifier in
> > the lower layer.
>
> may not be that obvious.
>
> So adding this explanation or the text proposed by Ben:
>
> > 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.

Well there are a couple of problems with this. Firstly, other than in 
some implementations, a tunnel (i.e. an LSP) is not really an interface. 
Secondly if the packet arrives on a data-link, we do require the the 
type indicator.

- Stewart