Benoit, Thanks for the thorough review. I will split my response into three sections to address the various ares you commented on.
(1). As for section 3 (network deployment requirements list and subsequent explanation), I will add text which clarifies this list expanded and described in the following sub-sections [new text on updated I-D] (2). Editorial comments at the tail end of the email [will review and make the updates to text] (3). As for you comments on RFC6888, the ones specified in this document are incremental to those. The "requirements" as stated here are ones related a deployment architecture (based on experience gained in actually going through the process). There are different then those listed in RFC6888 which concentrate on the NAT function itself. Here (in document) we concentrate on architectural/deployment requirements for deploying a system using NAT44. So by extension, no direct reference was made to RFC4787, RFC5328 or RFC5508 since these are more appropriate for someone building a CGN function. The reason for the references in section 3.7 and 3.8 are related to the fact that there is overlap between the architectural requirements and the the functional (NAT44/CGN function) requirement of the CGN box/device itself. This was in regard to (1) NAT logging which is both a requirement as stated in RFC6888 for the implemented of CGN box/device, but also a architectural requirement for an operator needed to facilitate the needs of the business. In section 3.8 there is mention of support for bulk port allocation. This again is a architectural requirement (to deal with practical scaling issues in real CGN deployments and ability to successful log) and as stated in RFC6888 a CGN device level requirement. Since there was existing text in RFC6888 which deal with NAT logging and port allocation (I.e. REQ-14 in RFC6888), we thought references to that RFC were appropriate. So, I will make updates on point 1 and 2 above. As for point 3, if you are satisfied with this explanation, then I can let it be. If you think you want to see text that specifically describes what I have put in my point 3 above, then I can do that as well. Regards, Victor K From: Benoit Claise <[email protected]> Date: Mon, 07 Oct 2013 13:57:08 +0200 To: <[email protected]> Cc: "[email protected]" <[email protected]> Subject: AD review: draft-ietf-opsawg-lsn-deployment-03 Resent-To: <[email protected]>, Victor Kuarsingh <[email protected]> Dear authors, - Section 3. CGN Network Deployment Requirements If a service provider is considering a CGN deployment with a provider NAT44 function, there are a number of basic architectural requirements which are of importance. Preliminary architectural requirements may require all or some of the following from the incoming CGN system: Then there is a long list of points. I spent some time on each point, making sure I understood it. Then, reading further, I realized that each point is expanded in the sub section. This should be explained up front. - I see Section 3 CGN Network Deployment Requirements What is the link with the requirements in rfc6888? Yes, there are a few references, for example in section 3.7 and 3.8 for specific requirements, but what about the other requirements. So the requirements in this document are 1. on top of the RFC6888 2. a subset of those that are important for draft-ietf-opsawg-lsn-deployment 3. a complete different set Btw, RFC6888 lists: > > 3 <http://tools.ietf.org/html/rfc6888#section-3> . Requirements for CGNs > What follows is a list of requirements for CGNs. They are in > addition to those found in other documents such as [RFC4787 > <http://tools.ietf.org/html/rfc4787> ], > [RFC5382 <http://tools.ietf.org/html/rfc5382> ], and [RFC5508 > <http://tools.ietf.org/html/rfc5508> ]. > Again, same question for these extra RFCs. Editorial: Abstract OLD: This document provides a practical integration model which allows the CGN platform to be integrated into the network meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. NEW: This document provides a practical integration model which allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. Section 1. Introduction OLD: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local local operator. NEW: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local operator. Section 2. Motivation OLD: The ability to replace IPv4-Only equipment may be out of the control of the operator, and even when it's in the administrative control; it poses both cost and technical challenges as operators build out massive programs for equipment retirement or upgrade. NEW: The ability to replace IPv4-only equipment may be out of the control of the operator, and even when it's in the administrative control, it poses both cost and technical challenges as operators build out massive programs for equipment retirement or upgrade. Section 2. Motivation OLD: This will include solving a number of challenges since subscribers who's connections require translation will have network routing and flow needs which are different from legacy IPv4 connections. NEW: This will include solving a number of challenges since subscribers whose connections require translation will have network routing and flow needs which are different from legacy IPv4 connections. Section 3.3 CGN By-Pass OLD: CGN By-pass can be accomplished in many ways, but a simplistic, deterministic and scalable model is preferred. NEW: CGN by-pass can be accomplished in many ways, but a simplistic, deterministic and scalable model is preferred. Section 3.5. Flexible Deployment Options OLD: Depending on hardware capabilities, security practices and IPv4 address availability, the translation environments my need to be segmented and/or scaled over time to meet organic IPv4 demand growth. NEW: Depending on hardware capabilities, security practices and IPv4 address availability, the translation environments may need to be segmented and/or scaled over time to meet organic IPv4 demand growth. - Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options Something weird with the section format, at least in the html version - A couple of acronyms - Flexibility should include integration options for common access technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ ASN-GW), and direct Ethernet; - expand large-scale NAT (LSN) Regards, Benoit
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
