Discussion:
[sunset4] Review of cgn-port-allocation draft
George, Wes
2014-02-18 17:55:20 UTC
Permalink
I had a fairly quick pass through this draft before the meeting and have some comments, as an individual (no WG chair hat) unless otherwise specified:

Section 2, 2nd paragraph– it’s unclear what this testing that you’re referring to is. If it’s external (e.g. A whitepaper or other published study), a citation would be useful. If it’s internal, some information on who, what, where, when and methodology used would help to establish the credibility of the testing as something that adds value as a data point in this discussion.

3.1 – probably should cite the relevant RFCs/sections for NAT vs NAPT. While many readers may be familiar with the difference, the reference is useful for those who are not.

3.3 “feature of double-translation” — citation/more explanation needed

4.1/4.4 – <WG Chair hat> I thought that the direction of the WG was to integrate the referenced drafts so that we had one draft that covers the solution space, not continue to reference them externally from an overview draft. Since there is no longer a Behave WG, these referenced drafts are orphans, and unless consensus changes, Sunset4 will not be progressing multiple overlapping NAT/CGN logging/mapping drafts. There is significant overlap between the solutions proposed by Donley and Tsou such that they can be merged into one solution with a couple of different variants of port assignment, I.e. Tsou is the simple case, and Donley is a potential optimization. This along with some discussion as to the pros/cons of each will be useful guidance.
</WG Chair hat>

5.1 “a testing was made” — see comment for section 2. Also, details about how the 40T value was reached (what amount of data per record, number of records per unit time. See donley’s intro section for an example. Also, I think that this section is really something that belongs earlier in the document, since it is the reason for there to be multiple methods of port allocation. This is the problem statement to the solutions being provided in donley/tsou.

There also needs to be discussion of state sync and failover/HA for the different solutions – how are things like existing mappings managed if a CGN fails and traffic switches to a backup, how do logging messages get updated, etc. See Donley section 3.1


Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Dan Wing
2014-02-24 07:01:11 UTC
Permalink
Section 2, 2nd paragraph– it’s unclear what this testing that you’re referring to is. If it’s external (e.g. A whitepaper or other published study), a citation would be useful. If it’s internal, some information on who, what, where, when and methodology used would help to establish the credibility of the testing as something that adds value as a data point in this discussion.
3.1 – probably should cite the relevant RFCs/sections for NAT vs NAPT. While many readers may be familiar with the difference, the reference is useful for those who are not.
3.3 “feature of double-translation” — citation/more explanation needed
4.1/4.4 – <WG Chair hat> I thought that the direction of the WG was to integrate the referenced drafts so that we had one draft that covers the solution space, not continue to reference them externally from an overview draft. Since there is no longer a Behave WG, these referenced drafts are orphans, and unless consensus changes, Sunset4 will not be progressing multiple overlapping NAT/CGN logging/mapping drafts. There is significant overlap between the solutions proposed by Donley and Tsou such that they can be merged into one solution with a couple of different variants of port assignment, I.e. Tsou is the simple case, and Donley is a potential optimization. This along with some discussion as to the pros/cons of each will be useful guidance.
</WG Chair hat>
5.1 “a testing was made” — see comment for section 2. Also, details about how the 40T value was reached (what amount of data per record, number of records per unit time. See donley’s intro section for an example. Also, I think that this section is really something that belongs earlier in the document, since it is the reason for there to be multiple methods of port allocation. This is the problem statement to the solutions being provided in donley/tsou.
And can we please, pretty please, get a comparison of that result with gzip or bzip2 or some other compression as is done by modern Unixes for their log files (newsyslog.conf)?

-d
There also needs to be discussion of state sync and failover/HA for the different solutions – how are things like existing mappings managed if a CGN fails and traffic switches to a backup, how do logging messages get updated, etc. See Donley section 3.1
Thanks,
Wes
Anything below this line has been added by my company’s mail server, I have no control over it.
-----------
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4
GangChen
2014-03-03 04:15:07 UTC
Permalink
Hi George,

Thank you for the comments. I apologize for the late reply. Please see
it inline.
Post by George, Wes
I had a fairly quick pass through this draft before the meeting and have
some comments, as an individual (no WG chair hat) unless otherwise
Section 2, 2nd paragraph- it's unclear what this testing that you're
referring to is. If it's external (e.g. A whitepaper or other published
study), a citation would be useful. If it's internal, some information on
who, what, where, when and methodology used would help to establish the
credibility of the testing as something that adds value as a data point in
this discussion.
The testing was made in our lab. I will elaborate the condition in the
next version.
Post by George, Wes
3.1 - probably should cite the relevant RFCs/sections for NAT vs NAPT. While
many readers may be familiar with the difference, the reference is useful
for those who are not.
3.3 "feature of double-translation" -- citation/more explanation needed
It will be added
Post by George, Wes
4.1/4.4 - <WG Chair hat> I thought that the direction of the WG was to
integrate the referenced drafts so that we had one draft that covers the
solution space, not continue to reference them externally from an overview
draft. Since there is no longer a Behave WG, these referenced drafts are
orphans, and unless consensus changes, Sunset4 will not be progressing
multiple overlapping NAT/CGN logging/mapping drafts. There is significant
overlap between the solutions proposed by Donley and Tsou such that they can
be merged into one solution with a couple of different variants of port
assignment, I.e. Tsou is the simple case, and Donley is a potential
optimization. This along with some discussion as to the pros/cons of each
will be useful guidance.
</WG Chair hat>
Thank you for the guidance. We will try to make further step in such direction.
A preliminary thought from my mind is to take the algorithm in
draft-donley-xx as basic to figure out the volume of each port segment

For allocation process, three possibility
Static: each port segment is designated to a particular user
Dynamic: each port segment is dynamically allocated to a user
Hybrid: users can be categorized as "a static group" and "a dynamic
group". For each group, port segments is allocated in static or
dynamic way respectively.

It's expected to be improved after the wg discussions.
Post by George, Wes
5.1 "a testing was made" -- see comment for section 2. Also, details about
how the 40T value was reached (what amount of data per record, number of
records per unit time. See donley's intro section for an example. Also, I
think that this section is really something that belongs earlier in the
document, since it is the reason for there to be multiple methods of port
allocation. This is the problem statement to the solutions being provided in
donley/tsou.
There also needs to be discussion of state sync and failover/HA for the
different solutions - how are things like existing mappings managed if a CGN
fails and traffic switches to a backup, how do logging messages get updated,
etc. See Donley section 3.1
It will be added


Many thanks

Gang
Post by George, Wes
Thanks,
Wes
Anything below this line has been added by my company's mail server, I have
no control over it.
-----------
________________________________
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this
E-mail and any printout.
Loading...