Joe Greco wrote:
> Okay, here, let me make it reaaaaaaallllllyyyyy simple.
Yes, indeed lets make it reaaaaaaallllllyyyyy simple for you:
> If your ISP has been delegated a /48 (admittedly unlikely, but possible=
> for $1,250/year, and they assign you a /56, their cost to provide that
> space is ~$5. They can have 256 such customers.
Fortunately ISP's get their space per /32 and up based on how much they
can justify, which is the amount of customers they have.
As such for a /32 single /48 is only (x / 65k) =3D like 20 cents or so?
And if you are running your business properly you will have more clients
and the price will only go down and down and down.
Really (or should I write "reaaaaaaallllllyyyyy" to add force?) if you
as an ISP are unable to pay the RIR fees for that little bit of address
space, then you definitely have bigger problems as you won't be able to
pay the other bills either.
There's a difference between "unable to pay the RIR fees" and "do not deem
any business value in spending the money." Engineers typically feel that
businesses should be ready and willing to spend more money for reasons that
the average business person won't care about.
Pretend I'm your CFO. Explain the value proposition to me. Here's the
(slightly abbreviated) conversation.
"Well, you say we need to spend more money every year on address space.
Right now we're paying $2,250/year for our /32, and we're able to serve
65 thousand customers. You want us to start paying $4,500/year, but Bob
tells me that we're wasting a lot of our current space, and if we were
to begin allocating less space to customers [aside: /56 vs /48], that we
could actually serve sixteen million users for the same cash. Is there
a compelling reason that we didn't do that from the outset?"
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...
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.
For some magic reasons though(*), it seems to be completely ludacrist to
do it this way, even though it would make the bill very clear and it
would charge the right amount for the right things and not some
arbitrary number for some other arbitrary things and then later
complaining that people use too much bandwidth because they use
bittorrent and other such things. For the cable folks: make upstream
bandwidth more pricey per class than downstream, problem of
heavy-uploaders solved as they get charged.
Sure, but that's how the real world works. The input from engineering
folks is only one small variable in the overall scheme of things. It is
a /mistake/ to assume that cost-recovery must be done on a direct basis.
There's a huge amount of business value in being able to say "unlimited(*)
Internet service for $30/mo!" The current offerings in many places should
outline this clearly.
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.