Skip to main content

Last Call Review of draft-ietf-opsawg-lsn-deployment-04

Request Review of draft-ietf-opsawg-lsn-deployment
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-01-06
Requested 2013-12-30
Authors Victor Kuarsingh , John Cianfarani
I-D last updated 2014-01-06
Completed reviews Genart Last Call review of -04 by Martin Thomson (diff)
Opsdir Last Call review of -04 by Joe Abley (diff)
Assignment Reviewer Martin Thomson
State Completed
Request Last Call review on draft-ietf-opsawg-lsn-deployment by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 06)
Result Almost ready
Completed 2014-01-06
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsawg-lsn-deployment-04
Reviewer: Martin Thomson
Review Date: 2014-01-06
IETF LC End Date: 2014-01-06
IESG Telechat date: (if known)

Summary:  This document describes a generic way that MPLS LSPs can be
deployed to support the deployment of CGNs in a way that addresses a
range of common requirements.  As a draft, it's still a little rough,
but it is mostly ready for publication as an Informational RFC.

Major issues: none

Minor issues:

The abstract says this:

  This document does not intend to defend the
   merits of CGN.

Which seems wise given their somewhat contentious nature.  But then
the entirely of Section 2 does exactly the opposite.  I don't know
what the right answer is here, but maybe the right thing to do is
delete Section 2.

Figures 1 and 2 should probably use different labels for the two CPE
boxes.  The top one is being translated, the bottom one isn't.

Section 6 is a little too speculative to be valuable.  How about using
the boilerplate:

      This document has no IANA actions.

I'm not sure what "security measures" might be employed here:

   If a provider plans to operate the pre-translation realm (CPE towards
   translator IPv4 zone) as a non-public like network, then additional
   security measures may be needed to secure this environment.

What might be secured in these scenarios?  Confidentiality?  Access to
network resources?  Perhaps this should talk about what a network
operator wants to secure: access to the network.  Then maybe talk
about access control and isolation.

In Section 4, this seems a little vague:

   Various redundancy models
   can be used within this architecture to support failover from one
   physical CGN hardware instance to another.

I don't expect an enumeration of the options, but this seems important
enough to at least point to where the redundancy options might exist?
Redundant "VPNs"/LSPs?  Redundant paths from the VRF termination?


Missing period in Section 9

I found the structure of the first part of Section 3.1 difficult:

   Centralized deployments of CGN (longer proximity to end user and/or
   higher densities of subscribers/connections to CGN instances) differ
   from distributed deployments of CGN (closer proximity to end user and
   /or lower densities of subscribers/connections to CGN instances).

Maybe this could be expanded a little to improve comprehension.

This statement seems redundant:

   Other requirements may be assessed on a operator-by-operator basis,
   but those listed above may be considered for any given deployment

As far as it goes, some of the requirements listed might not apply to
a particular deployment, or part thereof.