Re: [Softwires] map-t to proposed standard rather than experimental

I agree that we should move MAP-T out of experimental to a standard.  We are current looking at deploying
MAP-T in 2015.

Sent from my Verizon Wireless 4GLTE smartphone

----- Reply message -----
From: "Xing Li" <xing@cernet.edu.cn>
To: "Rémi Després" <despres.remi@laposte.net>
Cc: "Softwires WG" <softwires@ietf.org>, "IESG" <iesg@ietf.org>
Subject: [Softwires] map-t to proposed standard rather than experimental
Date: Sat, Nov 15, 2014 4:34 am

This is a very corner case (DF=1&MF=1), and it has been discussed in

page 8 (DF=1&MF=1) in http://www.ietf.org/proceedings/83/slides/slides-83-softwire-11.pdf

and if people really want to address this corner case (DF=1&MF=1), MAP-E can be used (only for the packets with DF=1&MF=1) without any problem, as shown  in (the mixed mode)

page 6 of http://www.ietf.org/proceedings/84/slides/slides-84-softwire-5.ppt

Regards,

xing

ps. Pretty much everything on the internet is incompatible with ICMP-based PMTU discovery, unfortunately.

Rémi Després 写道:

15 nov. 2014 01:40, Ted Lemon <Ted.Lemon@nominum.com><mailto:Ted.Lemon@nominum.com> :

On Nov 14, 2014, at 12:22 PM, Rémi Després <despres.remi@laposte.net><mailto:despres.remi@laposte.net> 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
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires