Hi Sasha, Thank you for valuable comments.
Indeed, authors didn’t look so far into details of PMTUD - we will try to address this in the next revision. Regarding required changes on ‘PE’ versus ‘P’ routers - each approach has it advantages and disadvantages, so, all approaches will be kept in the draft. In the next revision, we plan to add some comparative text, to compare each approach, where befits/drawbacks are clearly documented. Therefore, it is to early to say, that only one approach should be adopted. Best regards, -- Krzysztof Grzegorz Szarkowicz PLM, Senior Principal Architect Networking, Routing Infrastructure Solutions [email protected] +43 1 340 0100 1226 Hewlett Packard Enterprise HPE.com [PastedGraphic-2.png] On 2026 Oct 28, at 07:55, Alexander Vainshtein <[email protected]> wrote: Hi all, I have looked up the merged draft<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-alivar-6man-icmp-error-srv6-vpn-01__;!!NpxR!kkTx9-NnGIu3CNCcLUK__x9J4ZB0TfRewKPb0nCf01cOBjz_ak3J0d1td2To2LH0hlT-tGgeyqFNSMs1xkUDl9eUYvDznEJH8ba_xBRv$>, and I have a few comments. 1. I think that the main added value of the mechanisms defined in the draft is preservation of ability of the customer hosts residing in different site of an IP-VPN service instance to use existing Path MTU Discovery (PMTUD) mechanisms without any changes: * Today these mechanisms are used – and enabled by default – by all major operational systems but may be broken if IP connectivity between the hosts is provided by an IP-VPN service instance * The relevance of preservation of PMTUD discovery does not depend on the Uniform, Pipe or Short Pipe model being used by the PEs * For some reason PMTUD is not mentioned in the draft that seems to be focused on Traceroute functionality 2. From my POV: * Solutions that do not require any changes in the P routers are preferable to solutions that require such changes (for obvious reasons) * Procedures in the ingress PE may require some modification to provide effective PMTUD by the customer hosts 3. IMHO and FWIW, once the authors concentrate on a solution that does not involve changes in P routers, it should be adopted as a WG document either by either BESS or PRING WG. My 2c, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
