If we want to remove text that is not strictly protocol related, I'll then suggest we take the entire section 8.4 and the Appendix C out.
- Alain. On Aug 12, 2010, at 10:09 AM, Ralph Droms 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
