> On Jul 25, 2016, at 7:49 AM, Tom Herbert <[email protected]> wrote: > >> I object to GUE due to its inability to have a significant number of >> extensions in a regular and interoperable way. The base flags structure is >> limited (note 7 of 16 flags have already been used before the document has >> been published) and requires specific knowledge in the dataplane of all >> prior defined extensions to even parse a given field. The draft does have >> private data but since this is unstructured and untyped, it will be very >> difficult to make it interoperable between different users. In the past, >> ways around this have been proposed such as a flag indicating that an >> extended set of flags are present or overlaying the private data with some >> structure (such as TLVs). However, having multiple extension mechanisms in a >> single protocol seems overly complex and likely to result in incomplete >> implementations. >> > Jesse, > > As described in the GUE draft an optional flag extension field can be > added to provide another 32 bits of flags. That process could then be > repeated in the flag extension header field to give another 32 bits of > flags an so on. We have been running GUE for over three years now and > beyond the basics extensions (security, checksum, RCO, fragmentation), > I don't have reason believe we'll see new extensions in great > numbers-- at most one or two added a year. > > It is true that GUE does not have an open ended extensibility format > like Geneve. As you point out, it could be added, but I don't > currently see the need for that. Can you maybe shed some light on the > rationale and real use of TLVs in Geneve? How many TLVs have been > defined? What kinds of TLVs are being defined? How many TLVs are > present in individual packets? Are individual vendors creating their > own TLVs, and if so how are these interoperable?
In terms of Geneve TLVs, there are a number that I know of that are being used or have been proposed: * The INT telemetry framework that I mentioned in Berlin to collect data from the underlay (http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf) * OVN, open source network virtualization software uses Geneve to carry logical port information (https://github.com/openvswitch/ovs/blob/v2.5.0/ovn/ovn-architecture.7.xml#L960) * Cilium can use Geneve to carry policy labels between containers (https://docs.google.com/presentation/d/16s41VrUuHbaHUwWCkeSBa7DvY2O0PwVcOe-sO8TQ3o0/edit?usp=sharing) * In the remote checksum offload draft, you mentioned that the checksum offload field could be carried in a Geneve TLV (https://tools.ietf.org/html/draft-herbert-remotecsumoffload-00) * I guess it’s probably not much of a secret that VMware is planning on using Geneve as part of NSX (http://download3.vmware.com/vmworld/2014/downloads/session-pdfs/NET1674_Final_US.pdf) These have all more or less been defined by different organizations and different use cases. By having an open ended format, it becomes possible for new types to be defined very quickly and easily by anyone. I remember that a while back you were looking at defining remote checksum offload for VXLAN and weren’t really able to have a standard bit to use for this even though there was physically space in the header. I think if GUE were to be widely adopted and deployed you might actually run into the same problem - it would not be easy to quickly agree on an allocation of a bit. Since all implementations going forward would need to be updated to know at least the size, I suspect that it would not be an easy process. Private data might achieve the same purpose in some cases but there is probably little chance of it ever becoming interoperable with other implemetations. With Geneve TLVs, it is possible to define a new option with the intention of it becoming a standard or just as an experiment or private usage. In any case it is easy to allocate a type without having an impact on others’ implementation and yet is typed so that it can be picked up by others and interoperate if it proves to be useful. In terms of number of options, I would generally expect to see just a couple options on each packet. Typically if there is more than one this would be from different components that are layered together (i.e. network virtualization metadata could be one layer and telemetry could be another layer). These layers are often defined and work independently but within a layer interoperability is through any of the usual ways - public standards, open source, vendors working together, or private data center operators choosing to do their own thing. In practice all of those will happen and I don’t think that it’s necessary to try to force everyone through a single chokepoint. As a hypothetical question, how would you handle a situation where the security token you have defined for GUE is shown to be broken and needs to be replaced with a new option? I’m sure that in that case, you would feel the need to react immediately. It seems like the two choices would be to start using one of the unallocated flag fields and standardize and migrate before there is a collision with another option or resort to the private data field. Both seem to have some downsides. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
