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 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 mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>