Hi, Thanks for the feedback. Please see below my comments/responses.
Yours, Daniel On Sat, Jan 14, 2023 at 1:01 AM to...@strayalpha.com <to...@strayalpha.com> wrote: > Daniel, > > On Jan 13, 2023, at 8:33 PM, Daniel Migault <mglt.i...@gmail.com> wrote: > > f not, to better understand, do we have an example of a packet that cannot > be processed if the MTU is set to tunMAP but that can be processed if the > MTU is set to EMTU_R. > > > As per intarea-tunnels, MTU is a highly overloaded term. > > Tunnels relay packets that exceed their tunMAP but not their tunMTU > (EMTU_R - headers) using source fragmentation all the time. > correct, we need to remove encaps. However, that’s the issue. The reasons why what you’re trying to do isn’t > useful is already covered in detail in intarea-tunnels - and why not to do > it using IPv4 DF=0 in rfc6864. > > rfc6864 provides requirements of IP ID. DF=1 for inner and outer packet prevents using IP ID, but as mentioned DF=1 for outer is not possible in our case and I am not sure we can enforce DF=1 in the inner packet as well. Our proposal results in limiting fragmentation as well - when possible - and as such makes these requirements easier to meet. It’s not useful to have an email exchange rehashing that content message by > message. > > The conversation has been clarifying to us - at least regarding the terminology and we believe the document has improved, so that has been somewhat useful and we thank you for these feedbacks. While DF=1 is the recommended way, it is not an option for us - unless proven otherwise. **With DF=0**, we do measure some significant performance improvement by using our proposal and so far, I have been able to see any reasons for not doing it. If such reasons exist, it would be clarifying to explicitly mention them explicitly (to me and the WG) so these could be considered.. Joe > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
