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

Benoit Claise <bclaise@cisco.com> Fri, 18 October 2013 10:28 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 F14B411E8171 for <opsawg@ietfa.amsl.com>; Fri, 18 Oct 2013 03:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.577
X-Spam-Level:
X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.021, 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 e8gJObPwCBZS for <opsawg@ietfa.amsl.com>; Fri, 18 Oct 2013 03:28:03 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A65A821F9983 for <opsawg@ietf.org>; Fri, 18 Oct 2013 03:28:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24824; q=dns/txt; s=iport; t=1382092082; x=1383301682; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=A8AttbnQp/uATNriCRtni0M03qU+3f/P1trgA96/ufc=; b=Yy7Yk5Ok+QAbABnPUuABjtzeYjV9JPMR+thHGMDreHByV0aVLLupCcsS cG+jKyf4TXd+MPWcuArcE7o+rt1P3H9CbYm+e/qdBm66xYcaGWPyGIGUv tKBNsGvf20vgzJGPI+gubZgMp43sFNb50/0LxoDs3JIVJ3IcgFyxVHSH9 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYGAJEMYVKQ/khL/2dsb2JhbABagkNEOIlYrEyIRYElFnSCJQEBAQRnBQ0QCxEBAgECCh4HDwI1AwYIBg0BBQIBAYgCDMBdjgiBOAwFB4QpA5gJgS+FDItMgyY6gTQ
X-IronPort-AV: E=Sophos; i="4.93,521,1378857600"; d="scan'208,217"; a="160786268"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2013 10:28:00 +0000
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9IARujY022541; Fri, 18 Oct 2013 10:27:57 GMT
Message-ID: <52610D2C.70405@cisco.com>
Date: Fri, 18 Oct 2013 12:27:56 +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: Victor Kuarsingh <victor@jvknet.com>
References: <CE862C92.59524%victor@jvknet.com>
In-Reply-To: <CE862C92.59524%victor@jvknet.com>
Content-Type: multipart/alternative; boundary="------------050101040909050400000505"
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, draft-ietf-opsawg-lsn-deployment@tools.ietf.org
Subject: Re: [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: Fri, 18 Oct 2013 10:28:13 -0000

Hi Victor,

See in-line.
> Benoit,
>
> Thanks for the thorough review. I will split my response into three 
> sections to address the various ares you commented on.
>
> (1).  As for section 3 (network deployment requirements list and 
> subsequent explanation), I will add text which clarifies this list 
> expanded and described in the following sub-sections [new text on 
> updated I-D]
>
> (2). Editorial comments at the tail end of the email [will review and 
> make the updates to text]
>
> (3).  As for you comments on RFC6888, the ones specified in this 
> document are incremental to those.
> The "requirements" as stated here are ones related a deployment 
> architecture (based on experience gained in actually going through the 
> process).  There are different then those listed in RFC6888 which 
> concentrate on the NAT function itself.
> Here (in document) we concentrate on architectural/deployment 
> requirements for deploying a system using NAT44.  So by extension, no 
> direct reference was made to RFC4787, RFC5328 or RFC5508 since these 
> are more appropriate for someone building a CGN function.
>
> The reason for the references in section 3.7 and 3.8 are related to 
> the fact that there is overlap between the architectural requirements 
> and the the functional (NAT44/CGN function) requirement of the CGN 
> box/device itself.  This was in regard to (1) NAT logging which is 
> both a requirement as stated in RFC6888 for the implemented of CGN 
> box/device, but also a architectural requirement for an operator 
> needed to facilitate the needs of the business.  In section 3.8 there 
> is mention of support for bulk port allocation.  This again is a 
> architectural requirement (to deal with practical scaling issues in 
> real CGN deployments and ability to successful log) and as stated in 
> RFC6888 a CGN device level requirement.
>
> Since there was existing text in RFC6888 which deal with NAT logging 
> and port allocation (I.e. REQ-14 in RFC6888), we thought references to 
> that RFC were appropriate.
>
> So, I will make updates on point 1 and 2 above.  As for point 3, if 
> you are satisfied with this explanation, then I can let it be.  If you 
> think you want to see text that specifically describes what I have put 
> in my point 3 above, then I can do that as well.

 From your draft, the paragraphs referring to RFC 6888 are:

    To face this challenge, operators may need to deploy CGN (Carrier
    Grade NAT) as described in [RFC6888  <http://tools.ietf.org/html/rfc6888>] to help extend the connectivity
    matrix once IPv4 addresses caches run out on the local local
    operator.

      ...

    Operators may need to keep track of this information (securely) to
    meet regulatory and/or legal obligations._Further information_  can be
    found in [RFC6888  <http://tools.ietf.org/html/rfc6888>] with respect to CGN logging requirements (Logging
    Section).

      ...


      3.8. _Additional _CGN Requirements

    The CGN platform will also need to meet the needs of additional
    requirements such as Bulk Port Allocation and other CGN device
    specific functions._These additional requirements_  are captured
    within [RFC6888  <http://tools.ietf.org/html/rfc6888>].


The last paragraph ("additional" in the title and "these additional 
requirements") is my source of confusion I guess, and led to the 
question in my review

    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

You must already be compliant with RFC 6888. As you wrote: "As for you 
comments on RFC6888, the ones specified in this document are 
_incremental _to those"
And now you have some additional CGN requirements ... but those 
requirements are already captured into RFC 6888 ... to which you're 
already complaint. So what are those additional to?

Regards, Benoit
>
> Regards,
>
> Victor K
>
> From: Benoit Claise <bclaise@cisco.com <mailto:bclaise@cisco.com>>
> Date: Mon, 07 Oct 2013 13:57:08 +0200
> To: <draft-ietf-opsawg-lsn-deployment@tools.ietf.org 
> <mailto:draft-ietf-opsawg-lsn-deployment@tools.ietf.org>>
> Cc: "opsawg@ietf.org <mailto:opsawg@ietf.org>" <opsawg@ietf.org 
> <mailto:opsawg@ietf.org>>
> Subject: AD review: draft-ietf-opsawg-lsn-deployment-03
> Resent-To: <john.cianfarani@rci.rogers.com 
> <mailto:john.cianfarani@rci.rogers.com>>, Victor Kuarsingh 
> <victor@jvknet.com <mailto:victor@jvknet.com>>
>
> 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
>