Hi Brian, More to what you said about MTU, in general when tunnels return a Packet Too Big (PTB) message the message may be lost due to filtering middleboxes in the return path to the source of the originating packet. This can be especially problematic when the PTB reports a size less than 1500 bytes, since most original sources expect to see a minimum path MTU of that size. There may be certain circumstances under which the tunnel orientation would provide assurance against PTB message loss but (again in general) if this cannot be assured then the tunnel is susceptible to black holes unless outer IP fragmentation is used. By "outer IP fragmentation is used", I mean use it only until it is proven that it is no longer necessary - then, stop using it. Thanks - Fred fred.l.templin@xxxxxxxxxx > -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Brian E Carpenter > Sent: Saturday, May 24, 2014 1:46 PM > To: ietf@xxxxxxxx > Cc: nvo3@xxxxxxxx > Subject: Re: Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) > to Informational RFC > > A few comments below. I can't help feeling that NVO3 is creating > a monster, however. > > > 4.1. Pros & Cons > ... > > - Traffic carried over an overlay may not traverse firewalls and > > NAT devices. > > I don't know whether "may not" means "might not" or "must not", > and that completely determines what the sentence means. For example, > does it mean this? > - Traffic carried over an overlay might fail to traverse firewalls and > NAT devices. > > I suggest reviewing every instance of "may not" to avoid this > ambiguity. > > > - Hash-based load balancing may not be optimal as the hash > > algorithm may not work well due to the limited number of > > combinations of tunnel source and destination addresses. Other > > NVO3 mechanisms may use additional entropy information than > > source and destination addresses. > > Load balancing appears out of nowhere here. Are we supposed to assume > that load balancing is a requirement? Load balancing between what - > between different tenants, different physical DCs, different servers? > > Also, there seems to be an assumption that load balancing is only > based on addresses. Actually it's usually based on ports as well, > and more or less by definition they are invisible to the underlay. > So it's worse than "may not work well". > > I would have expected QoS support to also appear as a challenge, > for similar reasons. Isn't giving tenants a fair share of the underlay > capacity an issue? (There's a mention of traffic engineering later, > but surely you don't want this issue to be handled by operators > twiddling knobs?) > > > 4.2.4. Path MTU > ... > > TCP will > > adjust its maximum segment size accordingly. > > And how will that work for non-TCP traffic? > > > It is also possible to rely on the NVE to perform segmentation and > > reassembly operations without relying on the Tenant Systems to know > > about the end-to-end MTU. The assumption is that some hardware > > assist is available on the NVE node to perform such SAR operations. > > However, fragmentation by the NVE can lead to performance and > > congestion issues due to TCP dynamics and might require new > > congestion avoidance mechanisms from the underlay network [FLOYD]. > > In a word: yuck. Surely you should be recommending against anything like > that, or any attempt to re-segment TCP on the fly. > > > Finally, the underlay network may be designed in such a way that the > > MTU can accommodate the extra tunneling and possibly additional NVO3 > > header encapsulation overhead. > > Surely you should be recommending this, which is by far the safest > solution. (And of course it should allow for the IPv6 minimum MTU.) > > > 7. References > ... > > [NVOPS] Narten, T. et al, "Problem Statement : Overlays for Network > > Virtualization", draft-narten-nvo3-overlay-problem- > > statement (work in progress) > > Nit: that draft was replaced a long time ago by > http://tools.ietf.org/html/draft-ietf-nvo3-overlay-problem-statement > (which is already in the RFC Editor queue). > > Brian