This is very good summary of the motivation for extensions. GUE design was given quite thought on that.
For supporting tunnel stitching (draft-yong-nvo3-tunnel-stitching), it requires a new field in the encap. protocol to carry the next tunnel identifier. GUE can easily support that by defining a new flag and corresponding optional field. Extensibility is important for a protocol to retain long. Lucy -----Original Message----- From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tom Herbert Sent: Thursday, August 18, 2016 6:25 PM To: nvo3@ietf.org Subject: [nvo3] Extensions in nvo3 encapsulations Alia has asked that we provide some more information as to what the motivations for extensions are for nvo3 and to what form they should take. Here is some high level explanation with respect to GUE. Six fundamental extensions have been defined for GUE 1) VNID (draft-hy-nvo3-gue-4-nvo-03) 2) Checksum (draft-herbert-gue-extensions-00) 3) Remote checksum offload or RCO (draft-herbert-gue-extensions-00) 4) Fragmentation (draft-herbert-gue-extensions-00) 5) Security (draft-herbert-gue-extensions-00) 6) Payload transform (draft-herbert-gue-extensions-00) All of these share some common properties: * The extensions seem cover three areas: integrity/security, addressing, and protocol processing. * These extensions break down into two classes: those that can be processed without any additional information (checksum, RCO, fragmentation), and those that require context (VNID, security, payload xfrm).. * These are all intrinsic to the encapsulation layer and are part of correct processing of the encapsulation when present. For instance the security option is expressly needed to secure the GUE header and in particular to provide security for VNID. * All of these are mandatory in the sense that they can't be ignored at a receiver. For instance, if some receiver decided to ignore RCO then that would just become a checksum error at the ultimate receiver. Anything to do with security can pretty much never be ignored. Also, as a general principle in large scale DCs, it's much better to drop a packet when we're not sure something is correct as opposed to allowing it through even if the risk is slight. Packet loss is much easier to debug than incorrectness! * With the exception of fragmentation, a subset of these will commonly be set in packets for some deployment. For instance in a nvo3 deployment, VNID and security might be set all the time. * These are not intended for processing by middleboxes in transit. As I mentioned in my response to Bob Briscoe, intermediate devices cannot correctly parse UDP payloads (port number ambiguity problem in the network). Such information should be in HBH for IPv6 or IP options in IPv4. * These are interoperable and not proprietary.We allow proprietary extensions via a private data field but do do not encourage it, to do so otherwise would be to encourage vendor lock-in. While these six fundamental cover current needs, we cannot predict that they cover all the future needs of the protocol. At some point we will need to extend a deployed encapsulation protocol in the data center. The most likely scenario that we would need to extend the protocol is to addressed a newly discovered security vulnerability. We anticipate that extending a protocol is a rare event, but at large scale we need this capability. Extending a protocol is far simpler that replacing a protocol especially if we can avoid needing to swap out massive amounts of hardware. Another general characteristic is that GUE extensions are contained within a single header, as opposed to using shim headers or following headers. There are benefits to do this: * It's very clear that the extensions refer to the encapsulation. For instance if implement a checksum in a shim header then we need some consideration as to how the checksum covers prior headers. * We can limit the extensibility. This is important consideration for efficiency and avoid DOS attacks. * This allows "skip ahead". If a device just wants to look at the encapsulated IP packet for instance it does not need to parse a header chain for that. Thanks, Tom _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
