On 4/29/2015 8:01 PM, Xuxiaohu wrote:
> Hi Templin,
...
>> Existing tunnel protocols (IP*-in-IP*) are deficient in not providing a
>> tunnel
>> fragmentation mechanism per Section 3.1.7 of RFC2764.
>
> You may have noticed a fact that most modern routers and switches
> have been capable of processing jumbo frames for a long while. In
> other words, fragmentation could be completed avoided in most modern
> networks.
Jumbo frames are just a larger maximum frame size. Let's say that size is N.
We're talking about IP-in-IP, IP-in-UDP-in-IP, IP-in-GRE-in-IP, etc. In
all cases, you have:
N inside N+header
Unless the headers are 0 bytes long, the encapsulated result is always
larger than the interior contents.
I.e., if N is your limit, you've now exceeded it. The consequence is that:
any protocol that has non-zero headers and a packet maximum
always needs fragmentation to be encapsulated in itself
> Even in the sparse network environments where fragmentation
> is still unavoidable, the default configuration which have been
> widely supported by most vendors (see
> https://tools.ietf.org/html/draft-ietf-intarea-gre-mtu-03#page-4)
> should be enough in most cases. That's the reason why that's
> implemented by many vendors as the DEFAULT configuration, IMHO.
It's the default because it maximizes router vendor profit and/or
reduced router vendor cost, not because it maximizes network flexibility
or capability.
> BTW,
> it's preferable to avoid reassembling fragments at the tunnel egress
> due to the negative impact on the forwarding performance, AFAIK.
It is inherently unavoidable for IPv4 packets with DF=1 or all IPv6 packets.
> As
> such, it's not recommended to perform fragmentation on the tunnel
> layer and the outer IP layer.
It's provably required for IPv4 DF=1 and IPv6.
That's why we're trying to address it.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
