Le 2012-04-03 à 03:53, Satoru Matsushima a écrit : > 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. If you would have a detailed scenario where ANY transparency difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this sentence would be fair. However, you haven't shown such a scenario, and AFAIK you can't have one because it doesn't exist. The above assertion, being wrong, is therefore misleading. > I couldn't decide transport type to be unified with the new one. > No evidence, no expertise, no experience for that. But many of those who have no motivation to look for flaws that don't exist, do understand that the design is safe. > Do we need them to be sure in spite of we already have existing mature > transport variants? MAP-E+T isn't as mature as repeatedly claimed. MAP-T may be more imprecise than MAP-E in this respect, but both have known bugs to be fixed (at least packet IDs of shared-addres CEs of MAP-T, and BR hairpinning in MAP-E). Besides, the exact list of MAP DHCPv6 parameters has yet to be finalized. Cheers, RD > > 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
