Hi Peng, I think it is just example.
In case of this example, I think the standard of OSPF can't allow to use it for only inter-area routing. This standard can also allow to use it within only area 0. I think sometimes multiple solutions could be applied to solve the same problem. In case of this example, either OSPF or RIP could be applied. BTW, based on MAP draft, I think MAP can always keep the stateless mapping between ipv4 prefix, ipv4 address or a shared ipv4 address and an ipv6 address. It does not depend on the length of ea-bit. Even though ea-bit length is zero, rule ipv6 prefix is totally matched to the delegated prefix to CE and also ipv4 address based on rule ipv4 prefix can be associated with the ipv6 address based on the mapping rule. For this, I think MAP can keep the mapping functionality between ipv4 and ipv6 even though ea-bit length is zero. Thanks, Tetsuya On 2012/06/26, at 20:36, Peng Wu 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 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
