On Thu, Jul 31, 2014 at 5:56 AM, Paul Quinn (paulq) <pa...@cisco.com> wrote: > <removed LISP list> > > > On Jul 30, 2014, at 8:16 PM, Tom Herbert <therb...@google.com> wrote: > >> 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"? > > > You can’t generalize hardware parsing like that. The key for easy of parsing > is fixed sizes and known offsets. Stacking headers changes that. That isn’t > to say you couldn’t do what you suggest, but it would be more complex and > limits the value of the simple fixed size header. > I'm not trying generalize hardware parsing, I was trying to extrapolate how to use NSH to allow different meta data. Unless I misunderstand, NSH has similar properties to TLVs with the exception that they are fixed size. I do agree that fixed sizes and known offset are important for easy parsing, which is precisely why I'm leery about anything that looks like TLVs in such a low level data path.
The major parsing problem with TLVs (and I presume NSH if more than one header is allowed) is that the number of possible header combinations is combinatorial. For example, if there are 5 TLVs this generates 150 possible combinations. If we use optional flag-fields like in GUE (based on GRE) there would only be 32 possible combinations. The latter is much more amenable to HW parsing techniques like say a TCAM, not to mention the overhead to describe each TLV potentially increases TCAM width. We have already verified that both NICs and switches are capable of parsing GRE with various combinations of the defined variable headers (keyid, seqnum, csum). I take this as evidence that the is method of extensibility is HW friendly. _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
