Le 2012-04-03 à 11:31, Satoru Matsushima a écrit : > 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.
AFAIK, rfc5082 compatibility is ensured with TTL preservation that is in 4rd-u-06. Anything more? > > >> >>> 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. There is no such thing as "my 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. Just being tired to hear that the spec if clean and complete, and to have to find out myself what is missing. >> Besides, the exact list of MAP DHCPv6 parameters has yet to be finalized. Thanks for having implicitly acknowledged this fact (contrary to the claim that MAP is completely specified). > > Besides, 4rd-u is on the stage of pre-BOF discussion. Sorry to read this kind of argument from you. No other comment. RD > > cheers, > --satoru _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
