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

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

Le 13 août 2010 à 00:44, Yiu L. Lee a écrit :

> If 8.4 and Appendix C cause any concern, I agree with Alain to remove both
> sections.

+1 to delete them.
RD

> 
> 
> On 8/12/10 10:09 AM, "Ralph Droms" <[e-mail]> wrote:
> 
>> I think a lot of the text in section 8.4.1 is a matter of opinion or
>> speculation; perhaps it would be better to describe the pros and cons of
>> dynamic and fixed port assignment without making a recommendation before we
>> have much deployment experience.
>> 
>> - Ralph
>> 
>> On Aug 11, 2010, at 6:50 PM 8/11/10, Alain Durand wrote:
>> 
>>> 
>>> 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? This may or may bot be an issue if we
>>> are talking about 10k ports per customers,
>>> 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. And
>>> then what?
>>> 
>>> 
>>>>> 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.
>>> 
>>>   - Alain.
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>> 
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires