I have been reviewing the three encapsulations and have several comments on each. One aspect, however, seems to have not been discussed at all and I would like to highlight it here. This primarily applies to Geneve and GUE (though GUE does add MTU fragmentation at the encapsulator as an option), but is also not described for VXLAN-GPE although PMTU discovery and setting of the DF bit for IPv4 packets is required.
I found draft-saum-nvo3-pmtud-over-vxlan-03 to have some useful pieces of the problem and in specific to articulate the need for the VTEP to translate and relay ICMP messages back to the VM so that the MTU can be adjusted. In draft-ietf-nvo3-geneve-02 Sec 4.1, the use of PMTU discovery is recommended. Even if a router in the underlay is implementing RFC 4884, this guarantees at most 128 bytes of the incoming packet data. The expectation is that this will include all necessary headers. In this case, that needs to be enough for the VTEP to be able to relay and translate the ICMP message back to the VM. However, for Geneve and GUE, there is a real risk that 128 bytes is not sufficient to include the encapsulated IP header. If the underlay is IPv6, that takes up 48 bytes for the IPv6 header plus the UDP header. The base Geneve header is 12 bytes and an encapsulated IPv6 header is another 40. That leaves at most 28 bytes for the Geneve options - which is to say that at most 3 can fit. Of course, the situation with IPv4 is better - in that case 68 bytes are available for Geneve options. It is likely, of course, that there are a number of implementations that simply put in as much of the triggering packet as possible, but I'm not convinced that is an assumption that we can make. What solutions do you see in this space? Is there a reason that this wouldn't be an issue? The normal assumption is that the VMs would just be given an MTU that assumes the encapsulation; with variable options, I can guess that misconfigurations might happen as the options included changed. Regards, Alia
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
