On 2012/04/03, at 18:07, Rémi Després wrote: > > 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 already noticed rfc5082 as a detail. > >> 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. > I can't understand what you mean. Let us study it in your BOF. >> 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). > thanks, the authors of map suite are working to improve the documents. Don't worry about encapsulation and translation. > Besides, the exact list of MAP DHCPv6 parameters has yet to be finalized. > Besides, 4rd-u is on the stage of pre-BOF discussion. cheers, --satoru _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
