Yiu, What's your definition of "state" (as in stateful)?
-Woj. On 16 November 2012 00:19, Lee, Yiu <[email protected]> wrote: > Hi Rajiv, > > With all due respect, I disagree the analogy. Comparing MAP-E to routing > protocol is comparing apple to orange. MAP-E is not a routing protocol. > MAP-E won't synchronize or exchange states between two BRs. Instead, MAP-E > requires to statically provision states (aka rules) in the BR. Original > MAP-E describes a mechanism to reduce user states in BR by using > programatic logic. 1:1 MAP-E does not require any of the good stuff > defined in MAP-E. I just found it odd to combine stateful and stateless > mechanisms in a single draft and use a same name. > > Thanks, > Yiu > > > On 11/12/12 2:51 PM, "Rajiv Asati (rajiva)" <[email protected]> wrote: > > > > >Sure, and it is really a deployment choice (just like it is a deployment > >choice to use a dynamic routing protocol to advertise host routes or > >summary routes or both in an IP network). But that's not to say that we > >need one protocol for advertising the host routes, and another for > >advertising the summary routes. > > > >Cheers, > >Rajiv > > > >-----Original Message----- > >From: Yiu Lee <[email protected]> > >Date: Monday, November 12, 2012 1:33 PM > >To: Rajiv Asati <[email protected]>, Softwires-wg list <[email protected] > > > >Subject: Re: [Softwires] MAP-E 1:1 for HA > > > >>I am not talking about whether a MAP-domain should support 1 or N CEs. > >>What I am trying to say is MAP-E 1:1 requires the BR to know per > >>subscriber information and the operator must pre-provision per-subscriber > >>based rules to every BR in the same domain. In addition, the BR can't use > >>programatic logic to reduce states. When the WG first decided to work on > >>a > >>"stateless" solution, the goal was to make BR as stateless as possible. > >>MAP-E 1:1 in contrast requires to store all subscriber rules in the BR > >>and > >>can't derive the CE's IPv6 address using programatic logic. I found it > >>odd > >>to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a > >>stateful solution to me. > >> > >> > >>On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" <[email protected]> wrote: > >> > >>> > >>>One can define a MAP-domain consisting of 1 CE or N CEs. This is more of > >>>a > >>>deployment choice. > >>> > >>>Cheers, > >>>Rajiv > >>> > >>> > >>>-----Original Message----- > >>>From: <Lee>, Yiu Lee <[email protected]> > >>>Date: Friday, November 9, 2012 2:43 PM > >>>To: Softwires-wg list <[email protected]> > >>>Subject: [Softwires] MAP-E 1:1 for HA > >>> > >>>>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. > >>>> > >>>> > >>>>Thanks, > >>>>Yiu > >>>> > >>>> > >>>> > >>>> > >>> > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
