Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt
wang.cui1@zte.com.cn Wed, 26 October 2016 03:12 UTC
Return-Path: <wang.cui1@zte.com.cn>
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 35B4212940C; Tue, 25 Oct 2016 20:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.632
X-Spam-Level:
X-Spam-Status: No, score=-104.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 OAD0SOFb3Xh2; Tue, 25 Oct 2016 20:12:23 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA50127071; Tue, 25 Oct 2016 20:12:22 -0700 (PDT)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 2BA5D4C7681D2; Wed, 26 Oct 2016 11:12:20 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u9Q3AWYw043343; Wed, 26 Oct 2016 11:10:32 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn)
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B838FDC6E@MBX021-W3-CA-2.exch021.domain.local>
References: <147669153801.4599.10302546498954955094.idtracker@ietfa.amsl.com> <9D949D9D-FDB5-4512-B300-0DF3D2B00E38@alcatel-lucent.com> <CDF2F015F4429F458815ED2A6C2B6B0B838F61C5@MBX021-W3-CA-2.exch021.domain.local> <E8355113905631478EFF04F5AA706E98311067F4@wtl-exchp-2.sandvine.com> <f0df5c26-8da5-5f99-f241-31c4809bf2a7@joelhalpern.com> <OF00FB727E.7CD7D3F7-ON48258057.000DED69-48258057.000E5804@zte.com.cn> <CDF2F015F4429F458815ED2A6C2B6B0B838FDC6E@MBX021-W3-CA-2.exch021.domain.local>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.com>, Dave Dolson <ddolson@sandvine.com>
MIME-Version: 1.0
X-KeepSent: 6176DEC9:8FC2D9FC-48258058:000A0854; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF6176DEC9.8FC2D9FC-ON48258058.000A0854-48258058.00117332@zte.com.cn>
From: wang.cui1@zte.com.cn
Date: Wed, 26 Oct 2016 11:10:49 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-10-26 11:10:12, Serialize complete at 2016-10-26 11:10:12
Content-Type: multipart/alternative; boundary="=_alternative 0011732F48258058_="
X-MAIL: mse01.zte.com.cn u9Q3AWYw043343
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/Gj3DvZ-9ohbQM-SMzEOYoQeqdGs>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, sfc <sfc-bounces@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
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: Wed, 26 Oct 2016 03:12:26 -0000
Dear Ron, Unitl now, there proposed 3 use cases for SFC, including Data center, Mobility and Broadband use case. Different use case use different metadata allocation. If there is no other use case, 2 bits may be enough to distinguish 3 use cases. Otherwise, 2 bits would be not adequate. After long discussion about the NSH draft, I think it may be much more difficult to grow the fixed 16 bytes, but it also proposes a new approach to admit this issue. Unitl now, 5 approaches have been proposed: 1. from Ron: grow the fixed 16 bytes 2. from Gunter: overload NSH length field 3. from Dave: using MD type field, such as value 3,4,5.. 4. from Med: reckon to use MD Type=2 5. from Linda: let original MD Type field make 2 bits room for this purpose If it is possible, maybe someone can request a slot to discussion this issue during the upcoming meeting to achieve a consensus? BRs, Linda Wang Ron Parker <Ron_Parker@affirmednetworks.com> 2016/10/25 21:32 收件人 "wang.cui1@zte.com.cn" <wang.cui1@zte.com.cn>, "Joel M. Halpern" <jmh@joelhalpern.com>, "Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.com>, 抄送 sfc <sfc-bounces@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, Dave Dolson <ddolson@sandvine.com> 主题 RE: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt Linda, If we do, indeed, set the MD-1 encoding schema ID into the NSH, itself, it doesn’t seem like 2 bits would be adequate. Perhaps the fixed 16 bytes should grow to include a prepend byte(s) that identifies the encoding schema. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of wang.cui1@zte.com.cn Sent: Monday, October 24, 2016 10:37 PM To: Joel M. Halpern <jmh@joelhalpern.com>; Van De Velde, Gunter (Nokia - BE) <gunter.van_de_velde@nokia.com> Cc: sfc <sfc-bounces@ietf.org>; sfc@ietf.org; Ron Parker <Ron_Parker@affirmednetworks.com>; Dave Dolson <ddolson@sandvine.com> Subject: Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt Dear all, In fact, there is also another solution to address this problem proposed in a previous draft https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-02. It also proposed to add some bits in NSH, such as reserving 2 bits in the MD-Type field, to identify the exact meaning of the Mandatory Context Headers. This solution don't bother the length field as well as the MD-type=1/2. But is requires the original MD Type field to make 2 bits room for this purpose. On the other hand, I do agree that, both draft-wang-sfc-md-type-issues-02 and draft-vandevelds-sfc-nsh-overload try to propose the issue, we may agree/disagree on the different approaches, but there should find a agreeable solution for how to understand the exact meaning in the Mandatory Context Headers fields in mixed scenarios. BRs, Linda Wang "sfc" <sfc-bounces@ietf.org> 写于 2016/10/18 10:10:35: > "Joel M. Halpern" <jmh@joelhalpern.com> > 发件人: "sfc" <sfc-bounces@ietf.org> > > 2016/10/18 10:10 > > 收件人 > > Dave Dolson <ddolson@sandvine.com>, Ron Parker > <Ron_Parker@affirmednetworks.com>, "Van De Velde, Gunter (Nokia - > BE)" <gunter.van_de_velde@nokia.com>, "sfc@ietf.org" <sfc@ietf.org>, > > 抄送 > > 主题 > > Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh- > length-overload-00.txt > > I agree with Dave. The length field should always mean length. > One of the strong benefits of this is that if there is a need (for > logging, analysis, ...) to get to the data packet but not to understand > the metadata, the length field always just works. This significantly > simplifies many code paths. > > Yours, > Joel > > On 10/17/16 12:10 PM, Dave Dolson wrote: > > > > 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 AllocationIdentifier > > 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 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