On Tue, Mar 6, 2018 at 11:16 AM, Ole Troan <otr...@employees.org> wrote:
>> Agreed but note that draft tunnels will update that RFC in some important
> With other concerns than those raised in e.g. 4459 and 7597?
> Unfortunately there are cases where there are no other choice than to do
> fragmentation/reassembly on tunnel endpoints, but still the recommendation
> It is so problematic, that it is strongly recommended to engineer the network
> to avoid that happening.
That may be recommendation, but that is not was has been done all
networks. I worked in two very large datacenter networks that use a
lot encapsulation, but they didn't do anything special to engineer the
network for encapsulation. There was reluctance to set an MTU below
1500 and jumbo frames were always discussed, but in the end they
deploying them seem to be more complicated than it was worth. So
fragmentation did occur pretty regularly at tunnel ingress.
Fragmentation never popped up as a problem because of some mitigating
factors: 1) packets from the Internet be encapsulated usually were
already less than 1500 bytes(when encapsulating for VIPs) 2) This
always generated precisely two fragments 3) encapsulation is being
done on a closed network so there is no chance of DOS attack on the
reassembly cache (fragments from the Internet are dropped) 4)
encapsulation is otherwise rare relative non-encapsulation, so
lowering the MTU would only benefits the special case and hurts the
Int-area mailing list