Hi Edwin, Thanks for sharing you views. More comments below. ... >>> a result of the directorate reviews and the IESG review, it became >>> clear that the plan to advance MAP-T as experimental didn't make sense. >> AFAIK, not at all as clear as you say: >> - If both MAP-E and MAP-T would become standard, CPE providers would >> need to support (and maintain) both. > > [EJM] it has never been the case that just because a standard exists that > can be used on an element, that said suppliers of that element have to > implement the standard.
Sure: customer demand is the key. I was implicitly referring only to vendors that want their CPEs to interwork with all other CPEs that support v4/v6 stateless v4/v6 solutions as standardized in IETF. ... > I fully expect that MAP-T will be implemented in > production networks and having broad deployments of a protocol documented > in an experimental-track RFC seems to be in poor judgement. If there is sufficient customer demand for an experimental alternative to the standard, I can hardly see why a vendor would refuse to support it (in addition to the standard). Especially if it sells products to ISPs that supply all CPEs. >> - If both would become standard, full transparency to IPv4 fragmentation, >> which is guaranteed with MAP-E but not with MAP-T, would no longer be >> guaranteed to any customer, due to multiple standards. > > [EJM] This is not something I care about operationally. Note that, by not caring, you neglect what RFC4821 (standard track) recommends for path MTU discovery in IPv4. It use packets with MF=DF=1 (fragmented packets that may no longer be fragmented), a combination that is lost in MAP-T (and preserved in MAP-E). I know some people say it’s negligible, but this is IMHO a lack of understanding. > It seems like an > academic argument, not a practical one. - AFAIK, PMTU discovery serves a real purpose. - In any case, standardizing both MAP-E and MAP-T would require a modification of RFC4821. ... >> While the consensus on making MAP-E the only standard has held for long, >> re-visiting technical arguments would lead to an undesirable extra delay >> before the already-over-awaited MAP finalization. > > [EJM] My view is that this is a mischaracterization. The decision from my > POV was to move these drafts forward in light of a clear understanding > that there would be no converging around the religious debates. Remember > the coin flip ? That¹s not exactly a technical decision. The only decision I remember, is that MAP-E will the unique standard, and that both MAP-T and 4rd will be experimental. I recall that,first, the WG clearly wanted only one standard. Then, various supporters of MAP-E, and various supporters of MAP-T, voted that a combination of the 2 would not be 2 standards. (By doing so, it is a fact that they objectively increased their chances to find their preferred design in the standard). No consensus was reached on this 2=1, but not on 2=2 either. The coin flip that followed, decided by the chairs, was indeed an non-technical procedure, but it proved efficient: - After MAP-E has been voted to become THE chosen standard (with the two others as experimental), a clear WG consensus supported this as the final decision. - This was IMHO a remarkable chairs’ achievement in the difficult context of that time. CONCLUSION: If the IESG, now proposes 2 standards instead of 1, that’s a choice I view as based on a misunderstanding. I therefore vote against a WG support of this proposal. Regards, RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
