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