[Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04

Martin Thomson <martin.thomson@gmail.com> Mon, 06 January 2014 18:44 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344601AE17A for <gen-art@ietfa.amsl.com>; Mon, 6 Jan 2014 10:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzizODX73R9J for <gen-art@ietfa.amsl.com>; Mon, 6 Jan 2014 10:44:30 -0800 (PST)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0843D1AE15B for <gen-art@ietf.org>; Mon, 6 Jan 2014 10:44:29 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id z2so3193186wiv.1 for <gen-art@ietf.org>; Mon, 06 Jan 2014 10:44:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=OmZK9BsgJsncy69fHrUuCvl3q8i4p0MPE5Cx8YyJAtY=; b=xpOQ5Ik7iapla5Qk0x/b9fpmN1zEWqsYeQxpqULoObtFS1rLyqBk+Lg9ZUZ2Dje4nx 1ZF31wZyK7FdJKi1Gh21fswAGvCik78HnqCDk5mQFCcJGDbjiGJmLr9CNJ9B6fq4FUNR 7rqEdazb61kPX9JQcgg18iuk+DkvoB75Jr1oPqo+giukSpn0IdBxAJXwKSvju66n9H73 zsttwsw4WFaw9MCgfBmjBaWeMhva2l5aiMwHaMozPWEvt+1Da/mQk8sJIKUalbD6GksP ioI9HopqgOGrxGGf2vZK4frupgkRBt/dW9wL/4ELSER4CPgtqLXaiCiMHbrxmMkl6DNV eP3A==
MIME-Version: 1.0
X-Received: by 10.180.188.175 with SMTP id gb15mr13524873wic.50.1389033861049; Mon, 06 Jan 2014 10:44:21 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Mon, 6 Jan 2014 10:44:20 -0800 (PST)
Date: Mon, 06 Jan 2014 10:44:20 -0800
Message-ID: <CABkgnnXj07R25LQ64-=bha6iFpabgAt=xsRP0+5A20wnF8JUdQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: draft-ietf-opsawg-lsn-deployment.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Cc: "gen-art@ietf.org" <gen-art@ietf.org>
Subject: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 18:44:32 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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?

Nits:

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
   architecture.

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