Rajiv,
On Sat, Nov 10, 2012 at 2:45 PM, Rajiv Asati (rajiva) <[email protected]>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). > > 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. > Now that you need to optimize the implementation for different requirements, why not optimize it from protocol level ? So that every vendor would know how to implement for different requirements, rather than let operators pushing vendors one by one and tell them how to do. Without standardization, operators could still ask vendors to implement whatever they want. But standardization would reflect the common requirements from operators, and that would be easier for vendors to follow and implement. I do not understand why we do not follow this efficient way. Best wishes Qiong > 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/> > >=============================================== > > > > > > > > -- ============================================== 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
