v6 subnet size for DSL & leased line customers

Tue Dec 25 17:42:56 UTC 2007

Wow, is this what you folks do at Christmas ?

--
Leigh

Joe Greco wrote:
>> Right... Let's look at this in detail:
>>
>> /48 per customer == 65,536 customers at $2,250 == $0.03433/customer
>> /56 per customer == 16,777,216 customers at $2,250 == $0.00013/customer
>>
>> So, total savings per customer is $0.0342/customer _IF_ you have
>> 16,777,216 customers.  On the other hand, sir, for those customers
>> who need more than 256 subnets, we're running the risk of having
>> to assign them multiple noncontiguous prefixes. 
>>     
>
> Okay, here's a problem.  You keep making these statements which bear no
> resemblance to the real world.
>
> If I "need more than 256 subnets", and I approach my ISP to ask for such,
> there are at least two obvious answers which are incredibly more likely
> than any risk of "assign[ing] them[me] multiple noncontiguous prefixes."
>
> Answer 1: "We don't provide more space on your Cableco Cable Modem
> Service.  If you would like, we do offer Cableco Business Class Service."
>
> Answer 2: "We can assign you a larger prefix, however, you'll need to
> power cycle the cable modem and your addresses will change."
>
> Remember, this is residential broadband.  Saying /no/ is fairly common
> (in the same way that I can't get custom PTR DNS for a static IP address
> on a resi connection with many service providers.)
>
>   
>> Although the cost
>> of doing so is not readily apparent, each router has a limit to the  
>> number
>> of prefixes that can be contained in the routing table.
>>     
>
> Yeah, well, I'm not impressed.  As an operator community, we've been so
> good about getting our own affairs in order there.
>
>   
>> The cost of
>> upgrading all of our routers later probably far exceeds the $0.03
>> per customer that we would save.  Really, in general, I think that
>> the place to look for per-customer savings opportunities would
>> be in places where we have a potential recovery greater than
>> $0.03 per customer.
>>     
>
> How about /not/ upgrading all of your routers and keeping the "$0.03
> per customer"?
>
>   
>>> This discussion is getting really silly; the fact of the matter is  
>>> that
>>> this /is/ going to happen.  To pretend that it isn't is simply naive.
>>>
>>>       
>>>> How high are your transit&equipment bills again, and how are you  
>>>> exactly
>>>> charging your customers? ah, not by bandwidth usage, very logical!
>>>>         
>>> Perhaps end-user ISP's don't charge by bandwidth usage...
>>>       
>> True, but, they don't, generally, charge by the address, either.
>> Usually, they charge by the month.  If you can't cover $0.03/year/ 
>> customer
>> for address space in your monthly fees, then, raise your monthly
>> fee by $0.05.  I'm betting your customers won't care.
>>     
>
> Customers at the low end of the spectrum do in fact care, and my guess
> would be that they'd rather save the nickel than get extra address space
> that only 1 in 1,000 of them might ever get around to using.
>
>   
>>>> As an enduser I would love to pay the little fee for IP space that  
>>>> the
>>>> LIR (ISP in ARIN land) pays to the RIR and then simply pay for the
>>>> bandwidth that I am using + a little margin so that they ISP also  
>>>> earns
>>>> some bucks and can do writeoffs on equipment and personnel.
>>>>         
>>> Sure, but that's mostly fantasyland.  The average ISP is going to  
>>> want to
>>> monetize the variables.  You want more bandwidth, you pay more.  You  
>>> want
>>> more IP's, you pay more.  This is one of the reasons some of us are
>>> concerned about how IPv6 will /actually/ be deployed ...  quite  
>>> frankly,
>>> I would bet that it's a whole lot more likely that an end-user gets
>>> assigned a /64 than a /48 as the basic class of service, and charge  
>>> for
>>> additional bits.  If we are lucky, we might be able to s/64/56/.
>>>
>>> I mean, yeah, it'd be great if we could mandate /48 ...  but I just  
>>> can't
>>> see it as likely to happen.
>>>       
>> I'm betting that competition will drive the boundary left without  
>> additional
>> fees.  After all, if you're only willing to dole out /64s and your  
>> competitor is
>> handing out /56 for the same price, then all the customers that want  
>> multiple
>> subnets are going to go to your competitor.  The ones that want /48s  
>> will
>> find a competitor that offers that.
>>     
>
> Ah!  That's good.  Now we're making some progress.
>
> The first question most businesses have when they're spending money is
> "how much is it."  Not "how much is it on a per-customer basis."  If I
> go and ask for a new $2000 server so that I can put up some neat new
> thing, such as a reverse-traceroute webserver, the idea is that I should
> need to justify why it can't be done on an existing webserver.  Maybe it
> can, but maybe it can't (let's say because it'll connect out to our
> routers and the security risk warrants a separate server).  The fact
> that it might only cost a penny per month per customer is irrelevant to
> the higher-level analysis.
>
> In the same way, if an ISP can avoid spending money, there are almost
> certainly some who will do so.  Since the average customer is likely to
> be more than adequately served by 256 subnets for the foreseeable future,
> there will undoubtedly be some that allocate /56's (or even /64's).
> Market pressures, the actual needs of consumers, and whether or not it
> actually winds up as cheaper to support a single address space size on
> backroom systems will all work to shape what actually happens.
>
>   
>>> So, the point is, as engineers, let's not be completely naive.  Yes,  
>>> we
>>> /want/ end-users to receive a /56, maybe even a /48, but as an  
>>> engineer,
>>> I'm going to assume something more pessimistic.  If I'm a device  
>>> designer,
>>> I can safely do that, because if I don't assume that a PD is going  
>>> to be
>>> available and plan accordingly, then my device is going to work in  
>>> both
>>> cases, while the device someone who has relied on PD is going to break
>>> when it isn't available.
>>>
>>>       
>> Assuming that PD is available is naive.  However, assuming it is not is
>> equally naive. 
>>     
>
> No, it's not equally naive.  The bridging scenario is likely to work in
> all cases, therefore, assuming bridging as a least common denominator is
> actually pretty "smart" - even though I would prefer to see a full
> implementation that works in all cases.  Assume the worst, hope for the
> best.  If that's "naive", well, then it's all a lost cause.  You can call
> it "coldly cynical" all you'd like, though.  ;-)
>
>   
>> The device must be able to function in both  
>> circumstances
>> if possible, or, should handle the case where it can't function in a  
>> graceful
>> and informative manner.
>>     
>
> That much is certain.
>
> ... JG
>   