2012/4/3 Satoru Matsushima <satoru.matsush...@gmail.com>: > 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?
+1. With all due respect, I cannot image making a standard that has neither rough consensus nor running code. Regards, Wentao > > 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<despres.r...@laposte.net> 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 >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires -- Wentao Shang Master Candidate and Research Assistant at CERNET Center & NGN Lab, EE Department, Tsinghua University _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
