Let's get back to basics. The encapsulation and forwarding of packets between tunnel endpoints is supported by a combination of configuration state and mapped bits, if any.
There are 48 bits of IPv4 address+port space. You can map 0 or more of these bits into the 128 bits of IPv6 space. The more bits you map between IPv4 and IPv6, the less configuration state you need to support a given set of IPv4 endpoints over an IPv6 network. The less bits you map, the more configuration state you need for that same number of endpoints. The dial can be set to 0 mapped bits, somewhere in the middle, or even cranked all the way to 48 from a theoretical perspective (though IPv4 service with a single port seems pretty questionable, one never knows...). This is all easily supported with a single algorithm and a well-defined set of parameters which can be configured via CLI, DHCP, TR69, or pick-your-favorite-mechnanism. These well-defined set of parameters are the coefficients into the single common algorithm that the network equipment has to support. Having one configurable algorithm and protocol to support is far better for the CPE industry than two or more. Since this technology depends on the CPE industry for its success, it would behoove us to keep that in mind. We should also remember that the CPE industry is traditionally not particularly well represented in the IETF vs. large equipment vendors and operators, so we may have to listen especially carefully here. So to the point below, one protocol that supports two kinds of deployments is a Good Thing. In fact, the truly successful investments in standard protocols are those which are general and flexible enough to support uses the authors didn't even consider at the time (re: RFC 5218). - Mark On Nov 30, 2012, at 5:13 AM, Leaf yeh wrote: > 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
