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. > >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 >>>> >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
