Exactly. We will always choose the technique for its appropriate scenario. On Wed, Jun 27, 2012 at 11:36 AM, Peng Wu <[email protected]> wrote:
> On Wed, Jun 27, 2012 at 10:20 AM, Satoru Matsushima > <[email protected]> wrote: > > Hi Maoke, > > > > On 2012/06/27, at 10:48, Maoke wrote: > > > >> 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. ;-) > > > > That point would be an operational matter for deploying any standardized > technology. For example, an operator adopt OSPF to use its rich routing > feature but the network is small, the operator does just area 0 routing, > even OSPF allow inter-area routing for scale. Is an another ospf > specification needed for 'OSPF Area 0 Only Routing'? > > Well if I only have a simple network and I uses RIP, you don't make > OSPF somehow compatible with RIP(or just include RIP with an OSPF > terminology face? I don't know) and say "hey, just use this super > suite, don't consider it overloaded, it's for unity!" > > > > > > >> > >> 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. > >> > > > > Studying each significant use case is quite important. I agree on that > point with no doubt. However, is it IETF business for each use case > specification? > > > > 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 > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * ===============================================
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
