Mark - I think the only question that should be on the table is whether a 1:1 rule is called something different or not - kind of like how we refer to a /32 or /128 as a hostroute.
Even in the case of MAP-E 1:1, there still has 2 kinds of deployments: a. map PSID into the EA bits of the delegated end-user IPv6 prefix; b. length of EA bits = 0, which might mean no mapping at all; Best Regards, Leaf -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mark Townsley Sent: Thursday, November 29, 2012 10:04 PM To: Lee, Yiu Cc: [email protected] Subject: Re: [Softwires] MAP-E 1:1 for HA I think Rajiv's point is more about how summarization of routes in IP brings fundamental scalability advantages for IP routers, not whether the routes are programmed with a what is traditionally referred to as a "routing protocol" or via CLI, DHCP, netconf/yang, XML, or however the MAP rules are programmed in a given network. Another way of saying this is that, in IP (v4, for example here) a /32 route is no different than a /31, /24, etc. other than a /32 just happens to refer to one address rather than two or more. The routing system *could* be run with /32s everywhere, and while scalability would suffer tremendously, hosts would have the flexibility to be numbered with a static unique address no matter where the user connected to the network. The system would have IP mobility built right in! No need for Mobile IP tunnels! It's all possible right now, just turn the state dial all the way to the right and enjoy. The point where your existing equipment falls over requiring you to redesign the network accordingly depends on the number of hosts, limitations in routers, churn and convergence, etc. but there is nothing prohibiting this per se in the protocol design - it's all just IP and CIDR. Relating this to MAP: At one extreme, you can choose to setup rules in advance such that rule aggregation is possible to a degree whereby MAP can be supported inline with routers positioned where they normally would for regular IPv6 forwarding. At the other extreme, you have less aggregation and at some point you'll probably have to introduce special-purpose tunnel concentrator hardware at specific locations. The point where this crossover occurs isn't necessarily at the 1:1 MAP rule point, it could be 2:1, 8:1, 256:1... it all depends on how many MAP rules are supported by the vendor equipment chosen and the number of endpoints being addressed. Just as map supports 2^32:1,... 8192:1, 4096:1, 2048:1, 512:1, 256:1, 128:1, 64:1, 32:1, 16:1, 8:1, 4:1, or 2:1, it follows pretty clearly that it should also support 1:1 - to do otherwise would be arbitrary. I think the only question that should be on the table is whether a 1:1 rule is called something different or not - kind of like how we refer to a /32 or /128 as a hostroute. We could have a MAP "hostrule" for 1:1, and "aggregate-rule" for N:1. Vendor equipment optimized for 1:1 mode would advertise how many "hostrules" it can support. A more general MAP implementation might advertise x number of "rules", aggregate or not. The protocol mechanism from Softwires remains happily agnostic to all of this; To the protocol, its nothing more than semantics. Bottom line, "Stateless operation" is a variable tipping point... It's roughly the point where you can no longer affordably stuff all rules into all border routers in your network. If you have 2 rules for millions of endpoints, it's pretty easy to see that stateless operation is possible. If you have millions of rules for millions of endpoints, it's probably not. It's all highly dependent on the hardware, size, and design of the network. Softwires should focus on the best protocol design, and let the vendors, operators and market battle over where to turn the dial and what to optimize for in their implementations and deployments. - Mark On Nov 16, 2012, at 12:19 AM, Lee, Yiu 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
