15 nov. 2014 01:40, Ted Lemon <[email protected]> : > On Nov 14, 2014, at 12:22 PM, Rémi Després <[email protected]> wrote: >> If this is acceptable to whoever wants to deploy MAP-T, in due knowledge of >> its experimental status, it is not AFAIK acceptable in a standard. > > I do hear your point, Rémi.
Understanding in what MAP-T is incompatible with IPv4 PMTU discovery is then progressing. But, as shown below, your understanding of the point isn’t complete yet. > However, the problem actually exists in RFC 6145, not in this document, and > RFC 6145 is a standards track document. Misunderstanding of yours: the problem does not exist in RFC6145: - With the single translation of RFC6145, an IPv4 packet which is sent with DF=1 (as needed for PMTUD of RFC4821) will never be fragmented (neither before nor after translation). This is simply because IPv6 routers never fragment packets. => RFC4821 isn’t broken by RFC6145 - That is double translation that brings the problem: an IPv4 packet sent with DF=1 (as needed for RFC4821) can be fragmented after being translated back to IPv4. => RFC4821 is broken by MAP-T. > Also, this is a topic that the working group discussed and considered > addressed long before the coin toss. It is clear that real understanding of this point isn’t widely shared. (Even in your case, you needed to ask a number of clarifications). That’s what makes this contribution worth doing: decisions have to be made with consciousness of significant facts. > So I think this counts as re-raising an issue that was previously > addressed, and not as an issue that would have any bearing on the current > discussion. IMHO, a clear explanation of this contradiction between MAP-T and PMTU discovery of RFC4821 should be present in the draft itself. If I stopped spending energy to try and get it, it is because I felt a strong preference of MAP-T authors for keeping it concealed, and I had to move to other activities. Why then does the issue comes now? Because it is now that a proposal comes to promote MAP-T from experimental to standard. I am sorry that this contribution goes against a smooth and easy acceptance of an IESG goof faith proposal, but significant facts need to be known. Regards, RD PS: As this discussion continues, and as you didn’t answer my question about when the IESG should be informed, I hope you won’t find inappropriate my opening the channel now. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
