On Tue, Jan 19, 2016 at 4:13 PM, Jesse Gross <[email protected]> wrote: > On 1/18/16, 1:01 PM, "nvo3 on behalf of Tom Herbert" <[email protected] > on behalf of [email protected]> wrote: > > On Thu, Jan 14, 2016 at 12:27 PM, <[email protected]> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Virtualization Overlays Working > Group of the IETF. > > Title : Geneve: Generic Network Virtualization > Encapsulation > Authors : Jesse Gross > Ilango Ganga > Filename : draft-ietf-nvo3-geneve-01.txt > Pages : 26 > Date : 2016-01-14 > > Abstract: > Network virtualization involves the cooperation of devices with a > wide variety of capabilities such as software and hardware tunnel > endpoints, transit fabrics, and centralized control clusters. As a > result of their role in tying together different elements in the > system, the requirements on tunnels are influenced by all of these > components. Flexibility is therefore the most important aspect of a > tunnel protocol if it is to keep pace with the evolution of the > system. This draft describes Geneve, a protocol designed to > recognize and accommodate these changing capabilities and needs. > > A couple of comments... > > The discussion of efficient implementation (section 2.2.1) seems vague > to me. For example, from the draft: > > "As new functionality becomes sufficiently well defined to add to > endpoints, supporting options can be designed using ordering > restrictions and other techniques to ease parsing." > > What are these ordering restrictions? Does this mean TLVs have (or > might eventually have) some defined ordering as to how they can appear > in the packet? Would this contradict section 4.3: "Option ordering is > not significant". > > What are "other techniques to ease parsing"? > > > The draft is purposely trying to be agnostic to different implementations > and obviously doesn’t want to mandate any specific techniques. There are > several different types of software/devices and different architectures > within those classes so it would be difficult to say what the “right” way to > do things is today, let alone the future. However, given the number of > implementations that either already exist or are emerging, it seems like > this is a solvable problem. > That really doesn't answer my question. Let me rephrase it: "What are the normative requirements of Geneve with respect to TLV ordering?"
I would extrapolate that they are: 1) Per the protocol, TLV ordering is not relevant. A transmitter MAY send TLVs in any order. A receiver MUST accept TLVs in any order. Packets with the same options in a different order MUST be processed alike. 2) A transmitter SHOULD send TLVs in the prescribed ordering (by option class and type?). A receiver MAY optimize processing for the prescribed ordering. Tom > Thanks for pointing out the possible inconsistency in the text – I’ll take a > look at that. > > Jesse _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
