Hi Remi, Thank you very much for your comments and your reference. It is exactly what I want. Please see my comments inline.
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. > > [Qiong]: I'm not quite clear of the reason why "the longest IPv4 prefixes can be expected to progressively be reclaimed". The situation here is that these IPv4 prefixes (indicated as D1, D2, D3 in your draft) are disjoint prefixes with different lengths. Maybe we can firstly choose a shorter prefix (say D1 in your example). But after we have run out of this address pool, we have to choose another one from the remaining pools, and it is rather difficult to re-allocate existing IPv4 address pool unless this full IPv4 address customers do not exist anymore. Would you please explain it a bit more ? Thanks. > 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). > [Qiong]: Agree. The performance impact would not be a big problem for BR's. But we should still take our plan carefully with the region it covers. > > 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). > [Qiong]: As I have mentioned in another thread, indeed, special configuration should be applied to avoid potential non-continuous IPv4 prefix impacting on IPv6 routing. Best regards Qiong Sun > 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
