Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt

Simon Perreault <simon.perreault@viagenie.ca> Wed, 03 April 2013 13:58 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCEA21F86C1 for <behave@ietfa.amsl.com>; Wed, 3 Apr 2013 06:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 8vbW-VEWjZWA for <behave@ietfa.amsl.com>; Wed, 3 Apr 2013 06:58:15 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 493E121F862B for <behave@ietf.org>; Wed, 3 Apr 2013 06:58:14 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:ac04:7d6e:9b3e:38d3]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6B9BF4150E for <behave@ietf.org>; Wed, 3 Apr 2013 09:58:13 -0400 (EDT)
Message-ID: <515C35BD.7060503@viagenie.ca>
Date: Wed, 03 Apr 2013 15:59:25 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: behave@ietf.org
References: <CB1B483277FEC94E9B58357040EE5D023243183F@xmb-rcd-x15.cisco.com>
In-Reply-To: <CB1B483277FEC94E9B58357040EE5D023243183F@xmb-rcd-x15.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 13:58:15 -0000

Le 2013-04-03 15:19, Senthil Sivakumar (ssenthil) a écrit :
>> My reaction was different. I was thinking "only 10:1, this is pretty
>> good for static."
>
> Why so? With the same 15259 addresses that I have, I could add 10 times
> more subscribers,
> I can add up to 10Million subscribers as per this example, that is 10
> times more
> revenue. That was also the revenue lost, why is it good for business?

You're assuming that the limiting factor is addresses. You're assuming 
that even with dynamic allocation, the ISP is going to "fill" all its 
available public space. That's not what the text says. All the text says 
is that dynamic allows ~10 times more users behind each address than 
static. Nowhere does it say that static isn't "good enough".

>>> You spread the cost of 1.36TB across a 1,000,000 subscribers assuming
>>> cost of 1TB is US$80, we come to 0.00008 cents/subscriber/day or
>>> 0.024 cents/subscriber/month. Even with ASCII logging requirements
>>> this doesn¹t sound like a mammoth cost. Sure, there are other
>>> operating expenses involved
>>
>> The raw cost of storage is probably insignificant compared to those
>> "other operating expenses"...
>
> Can you put a dollar value to the significant other operating expenses?
> Does it offset the 10x revenue generated by doing dynamic
> port allocation and logging ? I think the key would be what the business
> proposition is at the end of the day.

It would vary per organization. An organization that is already well 
equipped in logging infrastructure and procedures would have a much 
lower cost deploying additional logging for CGN. But an organization 
that doesn't have this infrastructure would quickly say "no way!" and 
would look hard for alternatives. But all this is over-generalization, 
of course.

Simon