[ppml] Suggestion for ARIN to deligate smaller IP blocks
John Santos
JOHN at egh.com
Thu Jun 7 06:09:17 EDT 2007
- Previous message: [ppml] Suggestion for ARIN to deligate smaller IP blocks
- Next message: [ppml] Suggestion for ARIN to deligate smaller IP blocks
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, 6 Jun 2007, Jo Rhett wrote: > John, I'm a little confused by your math. > > 2000 customers * cost of changing IP addresses equals... $200 per > customer if they have to pay an outside consultant to do it for them, > usually less than $20 for inside help... Not a big number. > $40,000 <=> $400,000 Maybe $400,000 is noise to your company. My company has to think long and hard before spending $40,000. Your perspective is seriously warped. > > Cost of upgrading a single big iron box to have more routing table > slots > $100,000 > Multiply by the number of big iron boxes who can't use a default > route, say at least 400? Are you talking about the cost of upgrading all the backbone routers in the world to handle /25's vs. /22's? (I forget the size Leroy was originally looking for, but it was about 1/8 the minimum assignment under the current rules.) Aren't all these big boxes going to need to be upgraded anyway to support IPv6? > > The only difference is who is paying for it, and who is gaining value > for it. You want us to pay, so that your business can gain value. Who is "us"? > > You do the math, and tell me again why I should be paying out of my > pocket for your customer. You very well could have explicit > instructions sent to the customers for IP address changes. You could > very well purchase multiple IP ranges from different providers, and > thus make the importance of any IP address change negliable. Or you > could pay $49/month to get a second uplink and then qualify for PI > space based on multi-homing. Don't you need to be able to justify a /22 to get the PI multihoming space? That was the basis of this whole discussion. > > Every one of those options is trivially cheap and easy to implement. > This is why I reject your desire to make our businesses pay hard cash > so that your business can avoid building even the most trivial > resiliance into your process. Why does it cost your business any more if Leroy has a /25 that he is using most of versus if he has a /22 that he doesn't really need? Are you on about routing table size again, or something else? > > On May 31, 2007, at 4:39 PM, John Santos wrote: > > It is the 2000 customers who would have to pay the cost. It may be > > small for each, but its cumulative, and will certainly generating lots > > of support calls back to Leroy's company. > > > > My company is in a similar situation to Leroy's customers. We have an > > external mail filtering service. Our published MX records point to > > the service, and they then forward the (filtered for spam, viruses, > > RBL, etc.) mail to us, so we have had to open up our firewall to SMTP > > from their specific IP addresses. We are certainly *not* going to let > > them manage our firewalls for us, nor are we going to willy-nilly > > change > > our firewall rules on their request without minimally verifying the > > origin of the request (a support call to them.) Multiply by several > > thousand customers. > > > > If they were to start changing IP addresses frequently, we would start > > looking for a new service provider. > > > > This is an *extremely* unlevel playing field, since ACME GIANT ASP, > > INC. (which is many times the size of Leroy's company), could easily > > justify an allocation, and thus could promise their customers that > > their IP addresses and firewall rule would never change. > > -- > Jo Rhett > senior geek > > Silicon Valley Colocation > Support Phone: 408-400-0550 > > > > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539
- Previous message: [ppml] Suggestion for ARIN to deligate smaller IP blocks
- Next message: [ppml] Suggestion for ARIN to deligate smaller IP blocks
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list