Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs
draft-ietf-opsawg-lsn-deployment-06

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)
No email
send info
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)
No email
send info
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)
No email
send info
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?