On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) <kree...@cisco.com> 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"?
Thanks, Tom > - Larry > > On 7/30/14 2:46 PM, "Tom Herbert" <therb...@google.com> 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 >>>>nvo3@ietf.org >>>>https://www.ietf.org/mailman/listinfo/nvo3 >>> > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
