FYI, choosing MAP doesn't mean that committing to a 'single'. But choosing 4rd-u means that committing to a 'single'.
There're just transport variants, which are encapsulation, translation and new one we've never seen before. Proponents of the new one claim to unify transport only to the new one, which means that eliminating both encapsulation and translation variants of MAP because they say two choice of transport type would make confusion for operators. The new one is transparent than translation, but less than encapsulation. I couldn't decide transport type to be unified with the new one. No evidence, no expertise, no experience for that. Do we need them to be sure in spite of we already have existing mature transport variants? cheers, --satoru On 2012/04/03, at 2:47, Tom Taylor wrote: > People on the list might get the impression that Rene is single-handedly > holding up WG progress. I have not been involved in this work, but did > observe at the meeting a show of hands for 4rd-U at least as numerous as that > for MAP. For whatever reason, the WG at large does not seem prepared to > commit to a single solution. > > On 02/04/2012 11:17 AM, Wojciech Dec wrote: >> On 2 April 2012 15:46, Rémi Després<[email protected]> wrote: >> >>> >>> Le 2012-04-02 à 12:33, Ole Trøan a écrit : >>> >>>>> If this is to say that until a BOF is started, you will keep your >>> objection(s) unknown, I continue to take it as a lack of identified >>> objections. >>>> >>>> the objections I'm aware of are: >>>> - people are uncomfortable with only a double translation solution >>> >>> Are you furtively suggesting that 4rd-U has all limitations of a real >>> double translation solution like MAP-T? >>> That mays sound tactically smart, but isn't justified by facts. >>> >> >> Woj> Well, in terms of facts we have >> 1. 4rd-U does not supporting single translation mode, or if it does then is >> requires NAT64/BIH/Something else. (How anybody thinks that deploying 4rd-u >> + "something" else is manageable is a mystery) >> 2. 4rd-u is incompatible with NAT64 use or deployment >> 2. MAP solution (call it MAP, divi, or other variants) has proven deployment >> 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves >> problems that are non-issues to operators. >> 4. 4rd-u changes the basic structure/use of the v6 header, which is a >> change to IPv6 that needs to be vetted by 6man, etc. Creating such "novel" >> (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and >> use, effectively creates a new IPv6 protocol sub-class. >> >> Indeed 4rd-u deserves an "experimental" status track, more than anything. >> >> -Wojciech. >> >> >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
