Re: [Softwires] dual-stack-lite-06 - Too biased against static port sharing

[Rémi Després <[e-mail]>]

Hi Alain,
More in line.

Le 12 août 2010 à 03:50, Alain Durand a écrit :

> 
> On Aug 11, 2010, at 6:00 PM, Ralph Droms wrote:
> 
>> 
>>> 2. If the number of assignable IPv4 addresses is for a start multiplied by 10, by statically sharing ports of each address among 10 customers, this still leaves several thousands of IPv4 ports per customer. (Exactly 6144 ports per customer if, as appropriate, the first 4K ports, that include well-known ports and have special value are excluded). 
>> 
>> Agreed; one could argue that even sharing an IPv4 address among 5 customers allows 5x as many customers in the existing IPv4 address assignment, which should be more than enough to bridge the gap until IPv6 is available.
> 
> The later part of this comment is IMHO a matter of opinion... It is very hard to know for sure how much IPv4 translation will be needed in the feature.

> The major issue with any scheme that allocates a fixed number of ports is what do you do when that number is exhausted?  
> How do you even know this is happening?

The draft rightly accepts to put "a hard limit on the maximum number of port usable by single user".
I don't see why what is done when this maximum is exceeded wouldn't be also OK in case of fixed allocations.

> This may or may bot be an issue if we are talking about 10k ports per customers

... and even less with fixed allocation with 5 customers per v4 address ;-).
(This assigns 12,288 ports per customer, right?).

The point is not to recommend fixed allocation, but just to be neutral.

> , but as pressure mounts on the IPv4 space and the address compression ratio need to be increased, you soon end-up with much less ports per customers.

This is ignoring that, as more and more connections become IPv6, the number of IPv4 ports needed per customer will decrease.
The address-compression ratio possible with fixed allocations will increase accordingly.

> And then what?

In this respect, suggesting that host might safely continue to be IPv4-only because CGNs, DS-lite, PCP, TuRN STUN, ICE, etc. would in my understanding be extremely counterproductive. 
The only recommendation that IMHO makes sense is to asap enable dual-stacks, in client and server hosts, wherever it is possible.
If this is done, dynamic allocations might never be necessary in many places.

In any case, the point is not to prohibit overbooking.
It is only, in the context of DS-lite, to avoid recommending overbooking while there are clear circumstances where it isn't needed, and as it makes AFTR operation significantly more complex.


>>> 3. Where applicable static sharing is much simpler to operate.
>> 
>> Agreed.
> 
> Logs can indeed be simpler to manage, sure. But this is a trade-off. Other parts of the systems are more complex, see above.
> 
> All this being said, the discussion of the advantages or inconvenients of A+B belong  to the A+P mailing list.

This is a discussion is about fixed vs dynamic port allocations in the context of DS-lite.
The stake, which is an improvement of draft-ietf-softwire-dual-stack-lite-06, seems clearly in the scope of Softwire.

Regards,
RD


> 
>    - Alain.