Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs
Note: This ballot was opened for revision 04 and is now closed.
(Benoît Claise) Yes
(Jari Arkko) (was Discuss) No Objection
(Richard Barnes) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Spencer Dawkins) No Objection
Comment (2014-01-22 for -04)
This document was mostly accessible to readers not skilled in the art. Thank you. I did have some questions. Please consider them, along with any other comments you may receive. In section 3.7. Transactional Logging for CGN Systems CGNs may require transactional logging since the source IP and related transport protocol information is not easily visible to external hosts and system. If needed, the CGN systems should be able to generate logs which identify 'internal' host parameters (i.e. IP/Port) and associated them to external translated parameters imposed by the translator. The logged information should be stored on the CGN hardware and/or exported to an external system for processing. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would have guessed that an "external system" would be a log collector *inside* the operator's network, but the rest of this section seems to be using "external" to describe something that is *outside* the operator's network, and here it looks like "external" is *outside the CGN hardware*. Or am I misreading this text? In 4.2. Internal Service Delivery First, the provider can reduce the load on the translator since internal services do not need to be factored into the scaling of the CGN hardware (which may be quite large). ^^^^^^^^^^^^^^^^^^^^^^^^^^ is this actually saying First, the provider can reduce the load on the translator since internal services (which may be quite large) do not need to be ^^^^^^^^^^^^^^^^^^^^^^^^^^ factored into the scaling of the CGN hardware. (in other words, the load from internal services is quite large)? You might address the following comment by asking the Nomcom for smarter ADs, but in 4.4.2. Traffic Engineering Traffic Engineering can also be used to direct traffic from an access node towards a translator. Traffic Engineering, like MPLS-TE, may be difficult to setup and maintain. Traffic Engineering provides additional benefits if used with MPLS by adding potentials for faster path re-convergence. Traffic Engineering paths would need to be updated and redefined overtime as CGN translation points are augmented or moved. is "Traffic Engineering" obviously distinct from MPLS-TE? ... if everyone but me knows what is meant here, that's great, but if there was a reference given for "Traffic Engineering", I would know, too :-) There is a reference given for MPLS-TE, but not for "Traffic Engineering".
(Adrian Farrel) No Objection
Comment (2014-01-20 for -04)
I have no objection to the publication of this document. Here are a few thoughts for consideration... === Please add "(GRT)" after "Global Routing Table" in Section 4. --- Section 4.4 seems inconclusive. Would you consider adding some recommendations to the existing observations? -- I'd be interested to know whether you consider MPLS (data plane) security requirements are added by this architecture or if you think that existing IP (and higher) security is sufficient.
(Stephen Farrell) (was Discuss) No Objection
(Joel Jaeggli) No Objection
Barry Leiba No Objection
(Pete Resnick) No Objection
(Martin Stiemerling) No Objection
Comment (2014-01-21 for -04)
Section 4., paragraph 1: > The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre- > translated' realms within the service provider space into Layer-3 What is 'pre-translated'? I guess you mean private IP addresses or private realm, isn't it? I wonder why this document is not reusing already established terminology, e.g., from RFC 1918?