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" <[email protected]> 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 >>> [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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
