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