[OPSAWG] AD review: draft-ietf-opsawg-lsn-deployment-03

Benoit Claise <bclaise@cisco.com> Mon, 07 October 2013 11:57 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DE721E81C6 for <opsawg@ietfa.amsl.com>; Mon, 7 Oct 2013 04:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.554
X-Spam-Level:
X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0l32ZzqwX000 for <opsawg@ietfa.amsl.com>; Mon, 7 Oct 2013 04:57:15 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 870C521E8190 for <opsawg@ietf.org>; Mon, 7 Oct 2013 04:57:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11676; q=dns/txt; s=iport; t=1381147034; x=1382356634; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qKY70L5Z1QUdUc0KKt+JZBvFYbDwqIv6mF9d3JpxEOM=; b=deuVOAn/AZ9euMdOY0XVJy9aHg4k2OwHE1rnUohNjNQOK+0Ep1X8dIb5 lxZ+WOvKQaEBTtYlll5hMdryzzq4XrAzFzkbqG2LDJAGuicDS+6YrpEDx dPrQcaJRfHCWCwFUNvGfDV1Q4afr4Y3GM9xjHTZ4ceDImaGHcZDlXPigS k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFAFOhUlKQ/khL/2dsb2JhbABZgwc4iVe4FoEdFnSCJgEBBGcRARAsFg8JAwIBAgFFEwEHAQGIAgy6Z49RB4QjA5gBgS+FB4tKgyY6
X-IronPort-AV: E=Sophos; i="4.90,1050,1371081600"; d="scan'208,217"; a="18584647"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 07 Oct 2013 11:57:13 +0000
Received: from [10.61.194.168] ([10.61.194.168]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r97Bv8r4024015; Mon, 7 Oct 2013 11:57:10 GMT
Message-ID: <5252A194.6030700@cisco.com>
Date: Mon, 07 Oct 2013 13:57:08 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: draft-ietf-opsawg-lsn-deployment@tools.ietf.org
References: <525281E0.8020107@cisco.com>
In-Reply-To: <525281E0.8020107@cisco.com>
X-Forwarded-Message-Id: <525281E0.8020107@cisco.com>
Content-Type: multipart/alternative; boundary="------------080402030309090601000903"
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: [OPSAWG] AD review: draft-ietf-opsawg-lsn-deployment-03
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2013 11:57:20 -0000

Dear authors,

- Section 3. CGN Network Deployment Requirements

    If a service provider is considering a CGN deployment with a provider
    NAT44 function, there are a number of basic architectural
    requirements which are of importance.  Preliminary architectural
    requirements may require all or some of the following from the
    incoming CGN system:

Then there is a long list of points.
I spent some time on each point, making sure I understood it.
Then, reading further, I realized that each point is expanded in the sub section.
This should be explained up front.


- I see Section 3 CGN Network Deployment Requirements
What is the link with the requirements in rfc6888?
Yes, there are a few references, for example in section 3.7 and 3.8 for 
specific requirements, but what about the other requirements. So the 
requirements in this document are
     1. on top of the RFC6888
     2. a subset of those that are important for 
draft-ietf-opsawg-lsn-deployment
     3. a complete different set

Btw, RFC6888 lists:


        3 <http://tools.ietf.org/html/rfc6888#section-3>. Requirements
        for CGNs

        What follows is a list of requirements for CGNs.  They are in
        addition to those found in other documents such as [RFC4787  <http://tools.ietf.org/html/rfc4787>],
        [RFC5382  <http://tools.ietf.org/html/rfc5382>], and [RFC5508  <http://tools.ietf.org/html/rfc5508>].

Again, same question for these extra RFCs.


_
Editorial:_

Abstract
OLD:

    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.

NEW:
    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.


Section 1. Introduction
OLD:

To face this challenge, operators may need to deploy CGN (Carrier
    Grade NAT) as described in [RFC6888] to help extend the connectivity
    matrix once IPv4 addresses caches run out on the local local
    operator.

NEW:
To face this challenge, operators may need to deploy CGN (Carrier
    Grade NAT) as described in [RFC6888] to help extend the connectivity
    matrix once IPv4 addresses caches run out on the local
    operator.


Section 2. Motivation

OLD:

    The ability to replace IPv4-Only equipment may be out of the control
    of the operator, and even when it's in the administrative control; it
    poses both cost and technical challenges as operators build out
    massive programs for equipment retirement or upgrade.

NEW:
    The ability to replace_IPv4-only_  equipment may be out of the control
    of the operator, and even when it's in the administrative_control,_  it
    poses both cost and technical challenges as operators build out
    massive programs for equipment retirement or upgrade.


Section 2. Motivation

OLD:

    This will include solving a number of challenges
    since subscribers who's connections require translation will have
    network routing and flow needs which are different from legacy IPv4
    connections.

NEW:
    This will include solving a number of challenges
    since subscribers_whose_connections require translation will have
    network routing and flow needs which are different from legacy IPv4
    connections.

Section 3.3 CGN By-Pass

OLD:
    CGN
    By-pass can be accomplished in many ways, but a simplistic,
    deterministic and scalable model is preferred.

NEW:
    CGN
    by-pass can be accomplished in many ways, but a simplistic,
    deterministic and scalable model is preferred.


Section 3.5.  Flexible Deployment Options

OLD:
    Depending on hardware capabilities, security practices and IPv4
    address availability, the translation environments my need to be
    segmented and/or scaled over time to meet organic IPv4 demand growth.

NEW:
    Depending on hardware capabilities, security practices and IPv4
    address availability, the translation environments may need to be
    segmented and/or scaled over time to meet organic IPv4 demand growth.


- Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN 
Attachment Options
Something weird with the section format, at least in the html version

- A couple of acronyms

       - Flexibility should include integration options for common access
       technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
       ASN-GW), and direct Ethernet;
	
     - expand large-scale NAT (LSN)


Regards, Benoit