[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
- [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