Hi all,
I have looked up the merged
draft<https://datatracker.ietf.org/doc/html/draft-alivar-6man-icmp-error-srv6-vpn-01>,
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]
