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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Lucy yong [mailto:[e-mail]]
> Envoyé : mardi 18 octobre 2016 16:27
> À : BOUCADAIR Mohamed IMT/OLN; Van De Velde, Gunter (Nokia - BE); Carlos
> Pignataro (cpignata); Dave Dolson
> Cc : Ron Parker; [e-mail]
> Objet : 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.
> 

[Med] Agree. FWIW, we already have this text in the control requirement draft: 

   Also, this interface informs the SFC-aware SF about the semantics of
   a context information, which would otherwise have opaque meaning.

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

[Med] I agree with Joel here. The proposed NEW text does not solve the interoperability issue. It only acknowledges it. IMHO, we need to say more. 

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

[Med] Good point. Calling out explicitly those assumptions in the draft is a clear enhancement of the spec. BTW, if all is instructed via the control plane, I don't see why MD#1 would then mandate that the same semantic be applied along a chain/path/domain. I reckon that it is more natural in such case to use MD#2 (which I would like to see as a MANDATORY_TO_IMPLEMENT in the NSH draft, but that's another issue.).

> 
> Thanks,
> Lucy
> 
> Thank you.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : sfc [mailto:[e-mail]] 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; [e-mail]
> > 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:[e-mail]] On Behalf Of Van De Velde,
> > Gunter (Nokia - BE)
> > Sent: Monday, October 17, 2016 1:15 PM
> > To: Carlos Pignataro (cpignata); Dave Dolson
> > Cc: [e-mail]; 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)"
> > <[e-mail]>
> > wrote:
> >
> >
> >     > On Oct 17, 2016, at 12:10 PM, Dave Dolson <[e-mail]>
> > 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 [[e-mail]] on behalf of Ron Parker
> > [[e-mail]]
> >     > Sent: Monday, October 17, 2016 10:50 AM
> >     > To: Van De Velde, Gunter (Nokia - BE); [e-mail]
> >     > 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:[e-mail]] On Behalf Of Van De
> > Velde, Gunter (Nokia - BE)
> >     > Sent: Monday, October 17, 2016 5:15 AM
> >     > To: [e-mail]
> >     > 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, "[e-mail]" <internet-
> > [e-mail]> 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
> >     > [e-mail]
> >     > https://www.ietf.org/mailman/listinfo/sfc
> >     >
> >     > _______________________________________________
> >     > sfc mailing list
> >     > [e-mail]
> >     > https://www.ietf.org/mailman/listinfo/sfc
> >     >
> >     > _______________________________________________
> >     > sfc mailing list
> >     > [e-mail]
> >     > https://www.ietf.org/mailman/listinfo/sfc
> >
> >
> >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sfc
> > _______________________________________________
> > sfc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sfc