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

[Ballot discuss]

(1) 3.7: seems to not say enough about what's needed here -
the parenthetic "(securely)" isn't at all descriptive. I
think this should be easy enough to fix via a bit of text
and maybe some references that just call out the security
and privacy requirements associated with such logs.  Some
mention of RFC2804 would maybe be useful as part of that,
not sure.

(2) Section 8: Are there really *no* security
considerations when we add a big concentrator in the middle
of the network? Not even a bigger DoS impact if that
machine is DoSed? That is very hard to believe.

[Ballot comment]
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".

[Ballot comment]
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".  RFC 3031 gives

  [MPLS-TRFENG]      Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M.
                      and J. McManus, "Requirements for Traffic
                      Engineering Over MPLS", RFC 2702, September 1999.

[Ballot discuss]
Thanks for writing this useful document.

Before recommending the approval of the document, I wanted to discuss one thing. The last sentence of Section 6 is odd. Can this be removed? I believe you have already talked about this on e-mail and plan to do so, so I'm just checking that this was indeed the plan, and can then move on to approve the document.

In more detail: the sentence currently it gives an odd impression. We already have shared address space (as the document notes elsewhere), so it is not clear to me what the above might entail, particularly when (a) regular address space assignments go through the RIR system not IANA (b) use of unassigned address space is probably not something that we want to recommend and (c) if we need to do something beyond the existing shared address space allocation, then that probably deserves its own document.

[Ballot comment]

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?

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsawg-lsn-deployment-04 and has
the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CGN Deployment with BGP/MPLS IP VPNs) to Informational RFC


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'CGN Deployment with BGP/MPLS IP VPNs'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-01-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a framework to integrate a Network Address
  Translation layer into an operator's network to function as a Carrier
  Grade NAT (also known as CGN or Large Scale NAT).  The CGN
  infrastructure will often form a NAT444 environment as the subscriber
  home network will likely also maintain a subscriber side NAT
  function.  Exhaustion of the IPv4 address pool is a major driver
  compelling some operators to implement CGN.  Although operators may
  wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near
  term needs may not be satisfied with an IPv6 deployment alone.  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.  The model included in this document utilizes BGP/MPLS IP
  VPNs which allow for virtual routing separation helping ease the CGNs
  impact on the network.  This document does not intend to defend the
  merits of CGN.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed
Standard, Internet Standard, Informational, Experimental, or
Historic)? Why is this the proper type of RFC? Is this type
of RFC indicated in the title page header?

We are requesting publication as an Informational RFC.
Because the document describes a large-scale NAT deployment
scenario using BGP/MPLS VPNs, and does not specify a
protocol or protocols, it is appropriate for publication as
an informational document.

(2) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical summary: This document specifies a framework to
integrate a Network Address Translation layer into an
operator's network to function as a Carrier Grade NAT (also
known as CGN or Large Scale NAT).  The CGN infrastructure
will often form a NAT444 environment as the subscriber home
network will likely also maintain a subscriber side NAT
function.  The model included in this document utilizes
BGP/MPLS IP VPNs which allow for virtual routing separation
helping ease the CGNs impact on the network.  This document
does not intend to defend the merits of CGN.

Working group summary:  While there was clear support for
the document within the opsawg, there was little discussion
and no comments during working group last call.  However, the
authors were quite proactive about getting feedback from
operators outside the working group context, and having
that feedback posted to the working group mailing list, so
we feel that the document received satisfactory expert
review prior to and during last call.  (This was discussed
with the OPS ADs after closing working group last call).

Document quality: This is a well-written document that
clearly lays out the background, requirements, and
deployment scenarios using straightforward, unambiguous
language.  It received expert review from cable and telecomm
operators during its development, and the authors are
employed by Rogers Communication, a large Canadian telecomm
firm.

Personnel:  Melinda Shore is the document shepherd.

(3) Briefly describe the review of this document that was
performed by the Document Shepherd. If this version of the
document is not ready for publication, please explain why
the document is being forwarded to the IESG.

The document shepherd has read each version of the draft as
it has progressed, agrees that it is technically correct,
and feels that it is ready for publication.

(4) Does the document Shepherd have any concerns about the
depth or breadth of the reviews that have been performed?

No.  This document received extensive review from experts
outside the opsawg, including from CableLabs, Comcast, and
NTT. 

(5) Do portions of the document need review from a
particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took
place.

No

(6) Describe any specific concerns or issues that the
Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there
really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

None

(7) Has each author confirmed that any and all appropriate
IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79 have already been filed. If
not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this
document? If so, summarize any WG discussion and conclusion
regarding the IPR disclosures.

None

(9) How solid is the WG consensus behind this document? Does
it represent the strong concurrence of a few individuals,
with others being silent, or does the WG as a whole
understand and agree with it?

As described above, there was no comment during the working
group last call, and there has been no partisan orchestrated
political support.  However, there is clear consensus among
those who have reviewed the document that it is both
valuable and mature.  Again, this has been discussed with
the OPS area directors.

(10) Has anyone threatened an appeal or otherwise indicated
extreme discontent? If so, please summarise the areas of
conflict in separate email messages to the Responsible Area
Director. (It should be in a separate email because this
questionnaire is publicly available.)

No, there have been no dissenting comments.

(11) Identify any ID nits the Document Shepherd has found in
this document. (See http://www.ietf.org/tools/idnits/ and
the Internet-Drafts Checklist). Boilerplate checks are not
enough; this check needs to be thorough.

There are two outdated references, which will need to be
corrected prior to publication:


  == Outdated reference: A later version (-06) exists of
    draft-donley-behave-deterministic-cgn-05

  == Outdated reference: draft-donley-nat444-impacts has
    been published as RFC 7021

(12) Describe how the document meets any required formal
review criteria, such as the MIB Doctor, media type, and URI
type reviews.

Not applicable

(13) Have all references within this document been
identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the plan
for their completion?

No.

(15) Are there downward normative references references (see
RFC 3967)? If so, list these downward references to support
the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of
any existing RFCs? Are those RFCs listed on the title page
header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the
document where the relationship of this document to the
other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its
consistency with the body of the document. Confirm that all
protocol extensions that the document makes are associated
with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have
been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial
contents for the registry, that allocations procedures for
future registrations are defined, and a reasonable name for
the new registry has been suggested (see RFC 5226).

There are no IANA requests in this document.

(18) List any new IANA registries that require Expert Review
for future allocations. Provide any public guidance that the
IESG would find useful in selecting the IANA Experts for
these new registries.

None.

(19) Describe reviews and automated checks performed by the
Document Shepherd to validate sections of the document
written in a formal language, such as XML code, BNF rules,
MIB definitions, etc.

Not applicable.