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

Hi Lucy, all,

I didn't see yet implementation results that show that MD#1 is HW friendly compared to MD#2.

That said, MD#1 is underspecified as it leaves four fields without any meaning... which opens the door for interoperability issues.

draft-vandevelde-sfc-nsh-length-overload tries to address this problem. We may agree/disagree on the overloading approach but the authors have a point here:
* Given that various documents are associating a meaning with the 4 context headers of MD#1, how to help implementations know which variant to use?

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Lucy yong
> Envoyé : lundi 17 octobre 2016 22:32
> À : Van De Velde, Gunter (Nokia - BE); Carlos Pignataro (cpignata); Dave
> Dolson
> Cc : Ron Parker; sfc@ietf.org
> Objet : 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
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc