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