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<mailto:sfc-bounces@ietf.org>> 写于 2016/10/18 10:10:35:

> "Joel M. Halpern" <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
> 发件人:  "sfc" <sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org>>
>
> 2016/10/18 10:10
>
> 收件人
>
> Dave Dolson <ddolson@sandvine.com<mailto:ddolson@sandvine.com>>, Ron Parker
> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com>>, "Van De Velde, Gunter (Nokia -
> BE)" <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>, "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto: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<mailto: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<mailto: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<mailto:internet-drafts@ietf.org>" <internet-
> drafts@ietf.org<mailto: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<mailto:sfc@ietf.org>
> > https://www.ietf.org/mailman/listinfo/sfc
> >
> > _______________________________________________
> > sfc mailing list
> > sfc@ietf.org<mailto:sfc@ietf.org>
> > https://www.ietf.org/mailman/listinfo/sfc
> >
> > _______________________________________________
> > sfc mailing list
> > sfc@ietf.org<mailto:sfc@ietf.org>
> > https://www.ietf.org/mailman/listinfo/sfc
> >
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org<mailto:sfc@ietf.org>
> https://www.ietf.org/mailman/listinfo/sfc