Skip to main content

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

Yes

(Benoît Claise)

No Objection

(Barry Leiba)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Pete Resnick)
(Richard Barnes)
(Stephen Farrell)
(Stewart Bryant)

Note: This ballot was opened for revision 04 and is now closed.

Benoît Claise Former IESG member
Yes
Yes (for -04) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2014-01-20 for -04) Unknown
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 IESG member
No Objection
No Objection (for -04) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (for -05) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (2014-01-21 for -04) Unknown
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 IESG member
No Objection
No Objection (for -05) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2014-01-22 for -04) Unknown
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 IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection (for -05) Unknown