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 >> >
- [OPSAWG] AD review: draft-ietf-opsawg-lsn-deploym… Benoit Claise
- Re: [OPSAWG] AD review: draft-ietf-opsawg-lsn-dep… Victor Kuarsingh
- Re: [OPSAWG] AD review: draft-ietf-opsawg-lsn-dep… Benoit Claise
- Re: [OPSAWG] AD review: draft-ietf-opsawg-lsn-dep… Victor Kuarsingh
- Re: [OPSAWG] AD review: draft-ietf-opsawg-lsn-dep… Benoit Claise