Thank you for the comments. I'd seen it's great useful to improve the draft quality. Please see my reply inline.
2015-05-02 4:36 GMT+08:00, JF Tremblay <[email protected]>: >> On Apr 21, 2015, at 1:46 PM, George, Wes <[email protected]> >> wrote: >> >> This will start the two week adoption call for >> draft-chen-sunset4-nat64-port-allocation. This is the draft that >> previously was known as draft-chen-sunset4-cng-port-allocation but was >> renamed once the IPR-encumbered text was removed. >> >> http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/ >> <http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/> >> >> Please send support for adoption to the list, as well as any comments to >> improve the draft. This is a current charter milestone for the WG. > > > I’ve found the information presented in this document to be useful for > deployers of NAT64s and support its adoption. > > My general feeling of the document, however, is that many topics are > described very verbosely, sometimes in a confusing manner. It would be great > to use more to-the-point language and descriptions. Having a clear and > focused document on port {block,range} allocations techniques, sizes and > pitfalls would help the reader. Describing the vocabulary, design goals and > tradeoffs would also be useful. Great. You just hit the point. That is also my thinking how to improve the draft description. > > I had the following comments regarding the content: > > 2.2.2 "Preassigned port ranges occupy memory even when there are unused > ports." > Really? A range with two port numbers is negligible quantity compared to a > five-tuple or other data. I guess it may not only port information matter. One implementation I can see is it will also create mapping table when it reserves a port range. > 2.4.1 "The storage of log information may pose a challenge to operators, > since it requires additional resources and data inspection processes to > identify users." > The data inspection remark here does not make sense. The NAT might correlate > source addresses to user information if it has it available, but it won’t > inspect. The NAT does not store either. the issue is a NAT may don't know what source address should be correlated. Therefore, the NAT have to store entire information preparing the searching. For your information, the NAT should store at least three-months log in our networks. > 2.4.1 In the result table, the dynamic port-range allocation is dependant of > the range size and timing, that should be mentioned. (what values where used > to get to this result?) great. I will add in the next version. > 2.4.2: "The user's behavior normally correlates with system performance.” > Did you mean s/behavior/experience/ ? Otherwise I can’t grok this. Even with > that change, I’m sure if this sentence is useful. The sentence is not useful. I like the proposal that just directly going to the point . I will change the description. > 2.4.2: I’m not sure the reference to RFC6191 makes that much sense. RFC6191 > describes host behavior for incoming connections, while the goal here is to > safely optimize re-use of outgoing NAT ports. > As a side note, it might be useful to discuss the merits and problems > relating to TIME-WAIT assassination here. Got your point. It will be clear. > 2.4.3: Why not cover port block randomization here as well? Good to know more if you point me a reference of "port block randomization". > 3.2 The whole section about block timers is quite hard to follow. A block > may have an additional timer applied after all ports are free. Having a > clear definition here would help more than discussions around it. > > 3.2 6th paragraph suggests a very dangerous idea, that is to re-use ports in > the latest block as soon as possible. This has the potential of bringing > problems with rapid port re-use in blocks with very few available ports. > This also slows down block re-allocation and reduces port usage overall, > because of the typical port usage patterns (which is spiky in nature rather > than linear). > > 3.3 The recommendations on source port logging are superfluous in this > document. RFC6302 is well enough imo. Those three questions I would leave to my co-authors for more feedback. > > Things I didn’t see in this document that an implementer may be looking for: > > - Port allocation design goals. > - Clear definitions of port range allocation terms (including timers) > - Address stickiness concept definition > - Possible ratios of users per address and tradeoffs. > - The idea of a refresh log (in addition to start-end logs, for long-lived > blocks) > - Discussion on logging stability, timestamping, reliability. > - Discussion on port usage patterns and re-usage algorithms That is a good suggestion. Those information may implicitly described in the document. Again, I agree you general comments of " to-the-point language and descriptions." It hopefully will be clear when we improve the description. Best Regards Gang > JF > > > > _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
