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

Benoit Claise <bclaise@cisco.com> Fri, 18 October 2013 12:47 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 B403411E822E for <opsawg@ietfa.amsl.com>; Fri, 18 Oct 2013 05:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.578
X-Spam-Level:
X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.020, 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 t+JHvTu+iYA6 for <opsawg@ietfa.amsl.com>; Fri, 18 Oct 2013 05:47:24 -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 56EDB11E8295 for <opsawg@ietf.org>; Fri, 18 Oct 2013 05:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30056; q=dns/txt; s=iport; t=1382100438; x=1383310038; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=WRr06zYMOGkb6y7BmUtNCEcofnIYsDZsw/D+vXa6iNA=; b=Ip38PXzYZluX67jxC5rchqAeWZgS99JUtIlzbgkOyKvY08nIY1t1O0d5 uI27YEpluU8mYw70aBvCcI1+tlzzCPclrxFLqfG4dJLNAIAXaSypBFqlU zdObLpJIu1ziyObRBicfILjJifAPP4ueNEKpYpuZfGwUh6OaYjZbIt+EF 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigFAI0tYVKQ/khL/2dsb2JhbABagkNEOIlYtRqBJBZ0giUBAQEEZwUMARALEQECAQIKFgEHBwkDAgECATQDBggGDQEFAgEBiAIMwFWODYE4DAUHhCkDmAmBL4UMi0yDJjqBNA
X-IronPort-AV: E=Sophos; i="4.93,522,1378857600"; d="scan'208,217"; a="160790497"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2013 12:47:01 +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 r9ICkuAm002138; Fri, 18 Oct 2013 12:46:57 GMT
Message-ID: <52612DC0.3020007@cisco.com>
Date: Fri, 18 Oct 2013 14:46: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: <CE86A49F.59565%victor@jvknet.com>
In-Reply-To: <CE86A49F.59565%victor@jvknet.com>
Content-Type: multipart/alternative; boundary="------------040100080008090009000606"
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 12:47:29 -0000

Victor,
> Benoit,
>
> Ok, I see your point of confusion.  If 3.8 was called, "Base CGN 
> Requirements", and the text was modified a bit to not that other 
> architectural requirements are actually covered in RFC6888, would this 
> help remove the confusion and bring some clarity?
Yes, thanks.

Regards, Benoit
>
> Regards,
>
> Victor K
>
> From: Benoit Claise <bclaise@cisco.com <mailto:bclaise@cisco.com>>
> Date: Fri, 18 Oct 2013 12:27:56 +0200
> To: Victor Kuarsingh <victor@jvknet.com <mailto:victor@jvknet.com>>
> Cc: <draft-ietf-opsawg-lsn-deployment@tools.ietf.org 
> <mailto:draft-ietf-opsawg-lsn-deployment@tools.ietf.org>>, 
> "opsawg@ietf.org <mailto:opsawg@ietf.org>" <opsawg@ietf.org 
> <mailto:opsawg@ietf.org>>
> Subject: Re: AD review: draft-ietf-opsawg-lsn-deployment-03
>
> 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
>>
>