2012/4/3 Jan Zorz @ go6.si <[email protected]> > On 4/3/12 3:53 AM, Satoru Matsushima wrote: > >> 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 >> > > +1 > > Given the situation with IPv4 exhaustion we have to hurry and go with what > we know and what is proven to work today with no funky new features. > > I agree that 4RD-U brings some good new features, but as it changes the > IPv6 current usage I suggest to redirect 4RD-U to BoF and to go through > revision of also other working groups that needs to say their understanding > of changed IPv6 transport behavior. I also believe that when 4RD-U goes > through the whole proper procedure it might be widely adopted later as MAP > replacement. > > Meantime - let's fix the problem with what we know and understand. >
agree and have the same feeling. i'd love to keep study what 4rd-u brings to the transition architecture and more practices are not excluded along with the 4rd-u getting well-understood. and if 4rd-u is approved/improved/verified superior to both -T and -E through the whole procedure, i don't think it will be a problem that MAP would be obsoleted in the future. but that's of not our current situation, fixing the problem with well-understood building blocks is what we must do as soon as possible. - maoke > > Speaking as A+P (RFC6346) co-author, we got many questions about A+P > progress from operators and we learned that the time-frame for decision > between CGN and something else is already nearly expired. If we want > anything-A+P to still reach the operators, then the time for decision is > now. We already missed the majority of that train, but last seats in last > wagon are still reachable. > > We need to act and not just to push the endless discussion (that is not > that uncommon for any IETF WG :) ). > > Cheers, Jan Zorz > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
