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: Leigh Porter
  • Date: Tue Dec 25 12:44:36 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