Hi Paul, In a charter discussion, references to drafts typically serve to demonstrate that some progress has been made or is currently underway within the solution space. These drafts are presented as a starting point, which does not preclude the consideration of alternative proposals.
On Tue, Nov 26, 2024 at 1:51 PM Paul Wouters <p...@nohats.ca> wrote: > On Sun, 24 Nov 2024, Daniel Migault wrote: > > > I would like to add something around: Other protocols aim at > handling fragmentation as well as the management > > of > DSCP. draft-liu-ipsecme-ikev2-mtu-dect and draft-mglt-ipsecme-dscp-np are > expected to be considered as > > starting points. > > I don't think there is agreement on this. > > <mglt>Please provide clarification regarding the term 'this.' If you are suggesting that the drafts are controversial, we find this claim to be unfounded. We have gathered comprehensive feedback, and all suggestions have been meticulously assessed and deliberated upon within the mailing list. Additionally, concerning draft-liu-ipsecme-ikev2-mtu-dect, while our draft addresses fragmentation as specified in RFC4301, it is feasible for fragmentation to be managed by the router, as referenced in I-D.ietf-intarea-tunnels. Should this be your intended implication, I would advise you to read Section 1.2. This extension addresses a significant deployment challenge we are currently encountering and anticipate will become even more pressing in the future, and we aim to tackle it.</mglt> > Some people have argued this is an application level problem. > > <mglt>I understand that you are referencing draft-liu-ipsecme-ikev2-mtu-dect. It is important to highlight that we do not have authority over how applications manage fragmentation, and we must adhere to resource and latency constraints. Our approach aligns with RFC8900, which advises that each layer should manage fragmentation independently. Given that the IPsec layer is responsible for MTU probing while being aware of its own overhead, fragmentation can be managed with a high degree of precision. We believe this capability is difficult to replicate at the application level. </mglt> > I would argue that IPTFS solved fragmentation issues as well. > > <mglt>We anticipate that IPTFS will gain advantages from this draft, just as it does from PMTUD. It would be beneficial if you could identify which sections of the draft overlap with IPTFS. </mglt> > (some others blame just Linux for doing things wrong :) > > Paul > Yours, Daniel -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
