hi Remi, On Thu, Jul 28, 2011 at 9:37 PM, Rémi Després <[email protected]>wrote:
> Hi, all, > > How to use the 4rd stateless address mapping to support, in a provider > network having multiple IPv4 prefixes, both exclusive and shared IPv4 > addresses, is an typical question. > Jacni>: Yes, it is. As I mentioned in another thread, maybe in different way. I'd suggest some discussions about this should be added in the document. > Starting from a comment from Quiong Sun, here are some views on the > subject. > > > Le 28 juil. 2011 à 11:53, Qiong a écrit : > > > Hi, Remi, > > > > Thanks for your comments. I agree with you that in this situation, > stateless solution still superior to stateful ones from scalability aspect. > It is "per independent IPv4 prefix" mapping rule database, rather than > customer-based. But it still may have some tradeoff for domain realm. The > larger the domain it covers, the more independent IPv4 prefix there will be. > And also the whole domain has to synchronize these mapping rules. > > > > I think this problem would be quite common for large broadband service > providers who already have a huge amount of customers. Do we have to > transfer all these legacy customers with public IPv4 address into > shared-mode directly? In our consideration, we think it might be better to > offer shared-mode solution for new customers only and leave the legacy > customers with non-shared-mode solution to avoid complaint from address > sharing. > > > As a result, we have to deal with the co-existence scenario for at least > shared-mode and non-shared-mode. > > Yes, I think this will prove a frequent requirement. > > Complementary comments: > > 1. > A possible approach, to progressively reduce the number of used IPv4 > prefixes, consists in proposing two different tariffs: > - one for length L of IPv6 prefixes, and full IPv4 address per customer, > - the other, slightly lower, for length L+K of IPv6 prefixes, and shared > IPv4 address per customer. > > Thus the number of full-address customers can be expected to decrease, and > the longest IPv4 prefixes can be expected to progressively be reclaimed. > > Jacni>: The addresses are reclaimed progressively, that is one reason why we get fragmented prefixes. 2. > With a dihcotomic search for a prefix match in BR's and CE', the > performance impact of having a large number of rules can remain quite > limited, both in CE's and in BR's. > (Scalability of the BR function is in any case ensured by the fact that > BR's are, with respect to individual-customer states, completely stateless > (and also, of course, with respect to transport-connection states). > > 3. > By configuring appropriately as many mapping rules as there are IPv4 > prefixes, all IPv4 prefixes can be used without any impact on IPv6 routing > (no "IPv4 entropy" exported to IPv6). > Jacni>: In favor of this one, if I could. The Access gateway can be where the first aggregation happens. And we can have a *big* BR serving numerous Access Gateways belonging to seperate domains. Cheers, Jacni > This is illustrated in sec 3.2 of > tools.ietf.org/html/draft-despres-softwire-sam-01 (not too easy to read, > sorry for that, but the subject had some intrinsic sophistication and was > new). > (Incidentally this 4rd founding draft wasn't included Ole's 4rd-history > slide yesterday, but is IMHO worth looking at for anyone interested in the > genesis of 4rd.) > > Hope it helps. > > Regards, > RD > > > > I agree that this mapping specification can be applied to all stateless > solutions, separated from specific solution. Thanks for your suggestion. > > > > Best wishes > > > > Qiong Sun > > > > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
