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

Just notice this content of this thread. 

If we want to go this approach, using MD type is better way for it than using the length. This means to specify MD type specific semantics. Not sure if it can address SFC variety, we may need a more bits for MD type.  

The reason to have MD type 1 in NSH is hardware friendly, do we lose it by doing that?

Lucy

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Van De Velde, Gunter (Nokia - BE)
Sent: Monday, October 17, 2016 1:15 PM
To: Carlos Pignataro (cpignata); Dave Dolson
Cc: sfc@ietf.org; Ron Parker
Subject: Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

My understanding is that the only reason to not overload length is for consistency … It is easier, but not very useful and neither valuable usage of the field at all.

I do see great value in a stateless mechanism to understand how the metadata is structured… otherwise, why even have a NSH header if we could just stuff all state in the network flowstate? (Openflow and OVSDB could do the job perfectly with a central controller to distribute state)… however, It reduces value of NSH framework and adds operational complexity.

Using the SPI could work, but only if there are few bits reserved for this purpose… That is not the case and hence adds extra state in the network, to make the SF’s understand how the SPI and MD could be interpreted…

Hence the proposal to overload the length field… An alternative is to use for each allocation type a new NSH MD type and add maybe allocation context in the metadata content itself, which was suggested by Dave D.

G/

On 17/10/2016, 19:07, "Carlos Pignataro (cpignata)" <cpignata@cisco.com> wrote:

    > On Oct 17, 2016, at 12:10 PM, Dave Dolson <ddolson@sandvine.com> 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. 

    I agree with this. I’d much rather keep the Length to mean just Length for all MD Types.

    Thanks,

    — Carlos.

    > 
    > 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

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc