dear Satoru, 2012/6/26 Satoru Matsushima <[email protected]>
> On 2012/06/27, at 0:11, Qiong wrote: > > > Agree with Ian. > > > > MAP is designed and optimized for algorithmatic address mapping, but not > for per-subscriber rule mapping. Actually, the more you would like to > solve, more complicated it will become. > > > > I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E, > map-dhcp all becomes useless or not optimized. And I will not deploy > per-subscriber stateful and stateless solutions at the same. > > > > So I encourage two seperated approaches optimized for different > scenarios. It will be good for both. > > > > Do we really all forget about the "KISS" principle ? > > Not quite. > I believe that the most motivate to start this work in the wg has destined > MAP to be 'multi-protocol socket v2.0' that's what the former wg chair > wished to. Do you remember that? > i like the philosophy of "multi-protocol socket". however, i moderately doubt the "multi-protocol socket v2.0" is a perfect plan for every cases. in a quite good hotel, we see typically one 'multi-protocol socket' while a lot of local-standard sockets. i never think it will make me happy if i see every socket in my room is *multi-protocol*, occupying much spaces and quite noticeable on the walls. we need one to deploy somewhere not the only one type to deploy anywhere. ;-) therefore i understand the motivation of the wg is making a unified solution covering both encapsulation and translation in the framework of stateless, WITHOUT the exclusiveness against other solutions, more specifically suitable for a certain use case. cheers, maoke > > cheers, > --satoru > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
