> -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Larry Kreeger > (kreeger) > Sent: Wednesday, July 30, 2014 6:07 PM > To: Tom Herbert > Cc: David Melman; Marc Binderberger; LISP mailing list list; Dino Farinacci; > [email protected] > Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn- > vxlan-gpe-03 > > > > On 7/30/14 5:16 PM, "Tom Herbert" <[email protected]> wrote: > > >On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) > ><[email protected]> wrote: > >> Hi Tom, > >> > >> First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 > >>for NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly > >>following the VXLAN-GPE header would be an NSH header. One would > >>need to define a new MD Type (not the SFC value of 0x1, specified in > >>draft-quinn-nsh-03). > >> Then you need to make a decision as to whether you want to > >>possibility of your authentication value to be processed by hardware > >>or only software. > >> If you want hardware support, then I would recommend that it not be > >>encoded as a TLV. If you only care about software support, then you > >>could encode the authentication in a TLV using your own > >>organization's TLV Class, or perhaps an IETF TLV Class if you are > >>standardizing it. If you expect hardware to parse and validate the > >>VNI authentication, then I would encode it somewhere within the 20 > >>bytes following the base NSH header and not in a TLV. > >> > >Any optional data I define which proves useful in the datapath I may > >eventually want to implement in HW, and I really wouldn't want to have > >to make such a decision up front-- so I'll assume anything we'd want to > >define would need to go into NSH headers in order to keep HW support an > >option. So then in this model is it correct to say that the we could > >arbitrarily extend the protocol by using a chain of NSH headers each of > >which provides 20 bytes of data we can use for optional data and still > >be "HW friendly"? > > No, I would not necessarily say that. I think an arbitrary number of NSH > headers makes the expected offset of the payload vary in a similar way that > TLVs would.
[PG] The idea here is that TLV provides a way for the software to experiment and quickly light up new features without requiring changes to NIC offloads. Once the hardware support is needed for those, those TLVs can be converted to standard format metadata and put in the fixed header portion of the NSH header. Using different MDType, one can have a 20-byte fixed header or larger/smaller in future for different MDType. This provides a lot of extensibility in a way that is both hardware and software friendly. > > > > >Thanks, > >Tom > > > >> - Larry > >> > >> On 7/30/14 2:46 PM, "Tom Herbert" <[email protected]> wrote: > >> > >>>> I think the intent of NSH is to be generic enough to work at > >>>>different layers. The recent addition of the Metadata Type field > >>>>in the NSH header allows for it to be used for purposes beyond SFC. > >>>>It could theoretically be used to essentially extend the header of > >>>>the layer below it (e.g. > >>>> VXLAN/LISP). e.g. I think this could be used for Tom to carry his > >>>>64 bit VNI authentication. > >>>> > >>>I'd be interested to see exactly what the headers might look like in > >>>that case. I've tried to extrapolate from the SFC drafts how that > >>>might work but really don't see it... > >>> > >>>Thanks, > >>>Tom > >>> > >>>> - Larry > >>>> > >>>>>Just like any other UDP application. If that packet needs to be > >>>>>encapsulated that is a lower level function. Just like IP packets > >>>>>can go in an MPLS based LSP. > >>>>> > >>>>>> picture? They do mean something about how the packet is handled, > >>>>>>don't they? > >>>>> > >>>>>I won't answer that because those bit introductions into the design > >>>>>are indeed design bugs IMO. > >>>>> > >>>>>Dino > >>>>>_______________________________________________ > >>>>>nvo3 mailing list > >>>>>[email protected] > >>>>>https://www.ietf.org/mailman/listinfo/nvo3 > >>>> > >> > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
