16 nov. 2014 22:37, Tom Taylor <[email protected]> : > I'd replace "Warning" with the more conventional "Note".
Less explicit, but can be good enough AFAIAC. > I would also drop the last sentence on grounds of redundancy. This is NOT a > big issue as I understand from my reading of various lists, because > no one expects RFC 4821 discovery to work anyway. If this is true (which isn’t clear to me at all ) wouldn’t RFC4821 deprecation be the right action? Without that, considering here, implicitly, that RFC4821 is negligible would be too confusing. An alternative, to take your point, could be to add "in view of doubts expressed about RFC4821 practicability" after "negligible". RD > > Tom Taylor > > On 16/11/2014 11:55 AM, Rémi Després wrote: >> Hi Tom, >> >> If a statement proceeds to be added, I propose something like this in the >> introduction: >> >> Warning: on paths that traverse MAP-T IPv6 networks, ICMP-independent >> PathMTU Discovery, as specified in [RFC 4821], ceases to be reliable. (This >> is because DF=1/MF=1 combination, used in [RFC 4821], becomes DF=0&MF=1 >> after traversal of a MAP-T network). This specification is for service >> providers that, being conscious of this limitation, accept it as negligible. >> >> (This is, I believe, more explanatory here than what Gang had proposed in >> the different context of 464XLAT.) >> >> Regards, >> RD >> >> >> 16 nov. 2014 16:12, Tom Taylor <[email protected]> : >> >>> As a WG participant aware of the history of this whole effort, I would >>> support adding the statement to MAP-T in particular. >> >>> Tom Taylor >>> >>> On 15/11/2014 11:45 PM, Ole Troan wrote: >>>> Remi, >>>> >>>>>> It is true that double translation has the problem that the DF bit is >>>>>> not communicated through. This is a limitation of the MAP-T >>>>>> specification. >>>>> >>>>>> I've asked the authors about this, and they did not deny that this >>>>>> limitation exists, >>>>> >>>>> Good to know authors confirmed. >>>>> (Note that denial would have been difficult. That’s just a simple >>>>> technical analysis.) >>>>> But did they confirm my complete point, namely that MAP-T breaks the >>>>> ICMP-independent Path MTU Discovery of RFC4821? >>>>> If they didn’t, the fact remains, is important, and is also easy to >>>>> verify. >>>> >>>> while you may consider it simple, it took me quite some effort to refresh >>>> all the context necessary, thanks for providing the simple explanation of >>>> the issue. >>>> >>>> you are correct that MAP-T has this issue (or any double translation using >>>> RFC6145) including 464XLAT. >>>> >>>>>> so your claim that the authors are trying to conceal it seems a bit >>>>>> un-collegial. >>>>> >>>>> It seemed to you a bit un-collegial, but it certainly didn’t intend to be: >>>>> - To explain why I didn’t insist at that time to document the PMTUD >>>>> problem, I just said "I felt a strong preference of MAP-T authors for >>>>> keeping it concealed, and I had to move to other activities." . >>>>> - This is just the truth about what I felt then. >>>>> - In any case, if anyone is crossed by what I said, I apologize for >>>>> having told, in good faith but too frankly, what I had felt. >>>> >>>> not claiming to speak for all the authors here, but I don't think anyone >>>> was trying to conceal anything. I think it was more that we didn't feel >>>> that the issue was serious enough to warrant not reusing RFC6145 for >>>> double translation. (I also think someone did measurements in live >>>> networks looking for DF=MF=1 packets and found very few?) >>>> >>>> >>>>>> As I said, the working group did consider this issue, and it was not a >>>>>> factor in the coin toss. >>>>> >>>>> This seems to suggest that someone viewed this issue had been "a factor >>>>> in the coin toss". >>>>> No one did AFAIK, and certainly not me. >>>>> But this isn’t the point. >>>>> >>>>> Even in its experimental status, I do think MAP-T's specification should >>>>> have included a warning that it is incompatible with Path MTU Discovery >>>>> of RFC4821, and that MAP-E should be used if such compatibility is >>>>> desired. >>>>> >>>>> Yet, IMHO, harm of this warning being absent remains limited enough to be >>>>> acceptable as long as the status of MAP-T remains Experimental. >>>> >>>> we had this exact same discussion 464XLAT, RFC6877. in the end the >>>> disclaimer wasn't included in that document. >>>> >>>> I agree with you that the issue is worth pointing out though, with f.ex >>>> text similar to what was proposed for RFC6877. see: >>>> https://mailarchive.ietf.org/arch/msg/v6ops/66dSxb-i9kjGi1UeySBu5MYAV3w >>>> >>>> cheers, >>>> Ole >>>> >>>> >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
