Rajiv, Please see inline.
Thanks, Qi Sun On 2012-11-10, at 下午2:45, Rajiv Asati (rajiva) wrote: > > Let's not get into debating the local behavior e.g. Implementation > specifics (since one can argue that the router vendors can provide > comparable optimization for host routes as well as non-host routes). [Qi] This is not about implementations. But about the conflicts of two parts in one protocol. > > If I as a vendor were really bothered about host vs. non-host > control-plane & data-plane, then I could take the same standard (e.g. > MAP-E) and implement the preferred part with whatever optimization > possible [Qi]You mean implementing the preferred part with a method that is conflicting with the base protocol? I don't see a reason why we should do that. There is another protocol (e.g. lw4over6) perfectly suitable for the scenario, which is optimized by design. Vendors don't have to waste energy figuring out how to optimize. > without benefitting the non-preferred part. It really becomes an > implementation (local behavior) choice. > > We don't need more of the same thing. :) > > Cheers, > Rajiv > > -----Original Message----- > From: Qiong <[email protected]> > Date: Friday, November 9, 2012 11:05 PM > To: Ole Troan <[email protected]> > Cc: Softwires-wg list <[email protected]> > Subject: Re: [Softwires] MAP-E 1:1 for HA > >> >> >> >> Hi Ole, >> >> >> On Sat, Nov 10, 2012 at 9:41 AM, Ole Trøan >> <[email protected]> wrote: >> >> Yiu, >> >>> I have a question for the HA design concept of MAP-E 1:1. The central >>> theme of MAP-E is to make BR as stateless as possible and use Anycast >>> address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the >>> operator must have to pre-provision all the >> subscribe rules to all the BRs sharing the same Anycast address for >> reliable HA. This requires operators to carefully plan out which BRs >> support which subscribers. It is because BR is "per-subscriber stateful" >> in MAP-E 1:1 mode. Compared to the MAP-E design, >> HA in MAP-E only requires the operators to use the same set of rules to >> cover the entire domain. IMHO, this contradicts the original spirit of >> stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E >> name. MAP-E and 1:1 MAP-E are two completely >> different solutions and target to different deployment scenarios. I >> would love to hear others to comment in the ML how to resolve this issue. >> >> >> all nodes in a MAP domain must have the same rules. >> in 1:1 mode there is only the CE and the BR in the domain. >> >> having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn't >> mean you need a different RIB implementation. >> >> >> [Qiong] Actually, that's not the same. If we only need /32, there is no >> need to do LPM implementation anymore, only exact matching is needed and >> this is much eaiser than LPM. LPM is not optimized for /32 routing lookup. >> >> The reason that current routers still implement LPM rather not exact >> matching is because /32 is a truely corner case in RIB. However, if /32 >> is not a corner case, but is the major requirement for operators, I >> believe more efficient way should be introduced. >> >> Best wishes >> Qiong >> >> >> a host route which is what we have in 1:1 mode is just a corner case. >> what is "completely different" about it? >> >> cheers, >> Ole >> _______________________________________________ >> 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/ >> <http://sourceforge.net/projects/pcpportsetdemo/> >> =============================================== >> >> >> > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
