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'?


> 
> 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

Reply via email to