Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt
Dave Dolson <ddolson@sandvine.com> Mon, 17 October 2016 16:10 UTC
Return-Path: <ddolson@sandvine.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA39112962F for <sfc@ietfa.amsl.com>; Mon, 17 Oct 2016 09:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] 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 T4lO6jynMT3T for <sfc@ietfa.amsl.com>; Mon, 17 Oct 2016 09:10:20 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83821129538 for <sfc@ietf.org>; Mon, 17 Oct 2016 09:10:20 -0700 (PDT)
Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 17 Oct 2016 12:10:18 -0400
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0319.002; Mon, 17 Oct 2016 12:10:19 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt
Thread-Index: AQHSKFb3nGfrmaRz20ejmkNdPaiXgqCsuqOQgAAUwb0=
Date: Mon, 17 Oct 2016 16:10:17 +0000
Message-ID: <E8355113905631478EFF04F5AA706E98311067F4@wtl-exchp-2.sandvine.com>
References: <147669153801.4599.10302546498954955094.idtracker@ietfa.amsl.com> <9D949D9D-FDB5-4512-B300-0DF3D2B00E38@alcatel-lucent.com>, <CDF2F015F4429F458815ED2A6C2B6B0B838F61C5@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B838F61C5@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.142.18]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/kXZznvhUT4QSWEClMkoXMzMRbvM>
Subject: Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2016 16:10:25 -0000
I would prefer to see the length field always mean length, so that implementations not requiring metadata can just skip the metadata regardless of MD type. At the risk of stating the obvious, there already is an MD type field that can be used to discriminate metadata allocations. Values 3,4,5,... are available for different MD encodings. -Dave ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Monday, October 17, 2016 10:50 AM To: Van De Velde, Gunter (Nokia - BE); sfc@ietf.org Subject: Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt Gunter, I strongly support this proposal. It brings more specificity to Type 1 which will undoubtedly improve interworking between different implementations and between different administrative domains. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Van De Velde, Gunter (Nokia - BE) Sent: Monday, October 17, 2016 5:15 AM To: sfc@ietf.org Subject: [GRAYMAIL] [sfc] FW: New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt Short text about overloading NSH length field for NSH MD Type-1 as context allocation type, including proposal for backward compatibility. G/ ------ On 17/10/2016, 10:05, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote: A new version of I-D, draft-vandevelde-sfc-nsh-length-overload-00.txt has been successfully submitted by Gunter Van de Velde and posted to the IETF repository. Name: draft-vandevelde-sfc-nsh-length-overload Revision: 00 Title: Network Services Header Context Allocation Identifier Document date: 2016-10-17 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-vandevelde-sfc-nsh-length-overload-00.txt Status: https://datatracker.ietf.org/doc/draft-vandevelde-sfc-nsh-length-overload/ Htmlized: https://tools.ietf.org/html/draft-vandevelde-sfc-nsh-length-overload-00 Abstract: The specification of the NSH MD Type 1 header [draft-ietf-sfc-nsh] mandates four Context Headers, 4-byte each, and they MUST be added immediately following the Service Path Header. As direct consequence, an NSH MD Type 1 header is always Length 0x6 (six 4-byte words). As a result, the Length field of the NSH MD Type 1 header provides an information which is known by simply looking at the "MD Type" field. However, while [draft-ietf-sfc-nsh] does not specify the encoding of these Context Headers, other specifications have started to do so. A need to distinguish types of Context Headers therefore arises. This draft proposes to overload the Length field of an NSH MD Type 1 as Meta-Data context allocation identifier and to create a IANA repository for NSH MD Type 1 allocation schemes. The NSH MD Type 1 Length field overload intends to allow universal understanding at any network location and by any network device of the context allocation structure. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
- [sfc] FW: New Version Notification for draft-vand… Van De Velde, Gunter (Nokia - BE)
- Re: [sfc] New Version Notification for draft-vand… Ron Parker
- Re: [sfc] New Version Notification for draft-vand… Dave Dolson
- Re: [sfc] New Version Notification for draft-vand… Van De Velde, Gunter (Nokia - BE)
- Re: [sfc] New Version Notification for draft-vand… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-vand… Van De Velde, Gunter (Nokia - BE)
- Re: [sfc] New Version Notification for draft-vand… Lucy yong
- Re: [sfc] New Version Notification for draft-vand… Joel M. Halpern
- Re: [sfc] New Version Notification for draft-vand… mohamed.boucadair
- Re: [sfc] New Version Notification for draft-vand… Lucy yong
- Re: [sfc] New Version Notification for draft-vand… mohamed.boucadair
- Re: [sfc] New Version Notification for draft-vand… wang.cui1
- Re: [sfc] New Version Notification for draft-vand… Ron Parker
- Re: [sfc] New Version Notification for draft-vand… wang.cui1
- Re: [sfc] New Version Notification for draft-vand… Sumandra Majee
- Re: [sfc] New Version Notification for draft-vand… Joel M. Halpern