North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: v6 subnet size for DSL & leased line customers

  • From: Owen DeLong
  • Date: Mon Dec 24 10:26:39 2007

"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?"

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

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.

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.

That's how the real world works. I remember having to repeatedly involve
senior management in rejecting requests for /24s from customers who
could not justify them because our sales people at Exodus kept promising
them. The sales people continuously suggested that our competitors
were offering everyone /24s and that they had to do that to win the deals.

OTOH, "Raw bandwidth communications" seems to want to charge bandwidth
utilization not actually based on the bandwidth utilized, but, the number of
IP addresses routed. They are not my ISP for that reason.

Different providers have different business models.  Consumers will
find the provider with the business model that best fits their needs.
That's the way it works in the real world.

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

Owen