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

[Rémi Després <[e-mail]>]

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