Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

wang.cui1@zte.com.cn Tue, 25 October 2016 02:37 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 5B83F129469; Mon, 24 Oct 2016 19:37:05 -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 2tew_6Q3QZe1; Mon, 24 Oct 2016 19:37:02 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1C587129455; Mon, 24 Oct 2016 19:37:01 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id E6668F7696D33; Tue, 25 Oct 2016 10:36:57 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 1F00B200C79EB; Tue, 25 Oct 2016 10:36:58 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u9P2abYM074910; Tue, 25 Oct 2016 10:36:37 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn)
In-Reply-To: <f0df5c26-8da5-5f99-f241-31c4809bf2a7@joelhalpern.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> <E8355113905631478EFF04F5AA706E98311067F4@wtl-exchp-2.sandvine.com> <f0df5c26-8da5-5f99-f241-31c4809bf2a7@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.com>
MIME-Version: 1.0
X-KeepSent: 00FB727E:7CD7D3F7-48258057:000DED69; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF00FB727E.7CD7D3F7-ON48258057.000DED69-48258057.000E5804@zte.com.cn>
From: wang.cui1@zte.com.cn
Date: Tue, 25 Oct 2016 10:36:54 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-10-25 10:36:21, Serialize complete at 2016-10-25 10:36:21
Content-Type: multipart/alternative; boundary="=_alternative 000E580248258057_="
X-MAIL: mse01.zte.com.cn u9P2abYM074910
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/YVHVuDsY5SM13y2Ko7d-CmMz--c>
Cc: sfc <sfc-bounces@ietf.org>, "sfc@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
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: Tue, 25 Oct 2016 02:37:05 -0000

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