Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs
RFC 7289
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Benoît Claise; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Barry Leiba; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
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?
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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".
(Stephen Farrell; former steering group member) (was Discuss) No Objection
(Stewart Bryant; former steering group member) No Objection