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