A few more comments:.. General:
The use of the term frame versus packet are inconsistent. For instance, in section: "If the receiving endpoint does not recognize this option and this bit is set then the frame MUST be dropped." but later "Packets in which the total length of all options is not equal to the 'Opt Len' in the base header are invalid and MUST be silently dropped if received by an endpoint." I think both of these mean the same thing which is to drop the packet. IMO defining a Geneve frame is unnecessary. Showing outer Ethernet headers in header format does not add anything useful to the specification. For that matter, showing inner Ethernet headers is not necessary either since protocol type could be just as well be other Ethertypes (IPv4, IPv6, etc.). >From section 4.2: "some applications may limit the types of options which are supported or enforce a maximum number or length of options." This allowance permits applications to set the maximum number of options to zero, that is to say they don't have to support options at all. So what is to prevent Geneve TLVs from suffering the same fate of IP options which were obsoleted by decisions in implementation not to support them? >From section 3.3: "The checksum MAY be set to zero on transmit for packets encapsulated in both IPv4 and IPv6 [RFC6935]." RFC6935 does not give a blank check for disabling the UDP checksum is IPv6, there are restrictions and limitations. Please look at RFC7510 (MPLS/UDP) and GRE/UDP draft to see how those deal with this. Congestion considerations should also be taken into account. Please look at RFC5405 and how were dealing with the issue in GRE/UDP. >From section 3.4: "Since these are infrequent control messages, it is RECOMMENDED that endpoints direct these packets to a high priority control queue (for example, to direct the packet to a general purpose CPU from a forwarding ASIC or to separate out control traffic on a NIC)." I am dubious about this as a recommendation. To do this would require a lot of complexity in a NIC and is protocol specific. Such a thing could be done generally by implementing a high priority diff-serv queue and marking the IP header appropriately. But more than that, a lot of OAM is about validating a data path or measuring latency-- if control packets explicitly take a different path then their usefulness for such things is diminished. >From section: 3.5.1 "Sending endpoints MUST NOT assume that options will be processed sequentially by the receiver in the order they were transmitted." I think this should be worded as "receivers MAY process options in any order". But, you probably want to also allow that possibility that processing order might be relevant in cases like when options perform functions over payload so that there are ordering dependencies. For example, if one TLV gives CRC over the data and another performs compression they have to be processed in the opposite order that sender used to create the packet. Or maybe the intent is that all the TLVs in a list must be independent? Are duplicate options allowed in header (two or more TLVs with same class/type possibly different data)? If so, is there a requirement for processing order? "A particular option is specified to have either a fixed length, which is constant, or a variable length, which may change over time or for different use cases. This property is part of the definition of the option and conveyed by the 'Type'.": Is fixed vs. variable length indicated by a bit in Type then? If a receiver receives a fixed length type option but the length field is not the corresponding value, what is the action the receiver takes? More generally, I would infer that a critical option that is somehow malformed (bad length or or other wise) that the packet is to be dropped similar to dropping when a critical option is unknown. But, what if an option is not critical but is malformed. Should the packet be dropped, or should the option be ignored as though it is an unknown non-critical option? "For fixed length options, some implementations may choose to ignore the length field in the option header and instead parse based on the well known length associated with the type." This seems like a can of worms to me. It is allowing the length of a TLV to be determined in two different ways which opens the door to ambiguity when those two methods are in disagreement. Neither am I sure what the value is in ignoring the length field, any implementation will already have implemented the logic to parse variable length options anyway. One source of truth is always better! Tom 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-nvo3-geneve-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-geneve-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
