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

Hi Med,

I didn't see yet implementation results that show that MD#1 is HW friendly compared to MD#2.
[Lucy]  same here. If we want leave the control plane to define the MD#1 structure and expect that there are many, HW friendly is diminished. 

That said, MD#1 is underspecified as it leaves four fields without any meaning... which opens the door for interoperability issues.
[Lucy] Understand. If Section 3.4 adds text: this section only defines MD type 1 format. The semantics of MD Type 1 is outside the scope of this document. Thus, the use of MD type 1 is outside the scope of this document. -end. This will leave other document to address how to use it and interoperability issue.  

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?
[Lucy] agree with the point. If two SFC applications using different semantics of MD type 1 header run separately, i.e. no sharing any SF, they will not create an interoperability issue. Do we want to address the interoperability issue of MD#1 in this way or we want an SF implementation to be in an environment of multiple semantics of MD#1? 

Thanks,
Lucy 

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