Original message <96Jan27.012415-0000_est.20615+371@chops.icp.net> From: Sean Doran <smd@icp.net> Date: Jan 27, 1:24 Subject: Re: Policy Statement on Address Space Allocations ...

The encouragement, IMHO, should be in the form of the work PIER is addressing (sorry about the pun), some possible future renumbering tools, NATs, or any other technology which results in making a change of addresses painless and quick, so that people have little or no reason to object to using provider-supplied addresses.

Right. Exactly. But UNTIL such time as easy renumbering for everyone is a reality, watching a world where the policy of one of the big service providers collides directly with the policy of the address assignment agencies makes me wonder what whose goals really are, and really REALLY glad that the company I founded is as big as it is already. And that's because if I was starting that company TODAY, and I knew that in less than two years down the road I'd be in a position where I'd be multihomed and/or at an interchange point, I'd be stuck... because there's no way I could get an initial address block for assignment to my customers that was also big enough to pass Sprint's routing filters. I don't even understand how I'd effectively use such an address... If I get an address from my provider, I'm doomed to renumbering in the event that provider can't provide me with all the service I need, and I can't subject my customers to that. But the first "portable" block of addresses I could get (speaking hypothetically as a new ISP) wouldn't work to get everywhere, because Sprint (and no doubt others in the future) would ignore the announcement. Since those addresses would be worthless, there's no way I could ever use them, and thus no way I could ever satisfy the Internic that I'd effectively used my first block of addresses and was ready for a bigger one. I forsee a large number of new /19's filled with fictitious entities, followed immediately by the application for an additional, larger, block... and if we're concerned about the efficient use of address space (and not just routing table size) that's a serious waste. Why can't we just all agree, at least for a little while, on the SAME address efficiency vs. routing table size tradeoff? RIPE, et al has decided that initial assignments of /19 are the right tradeoff. Sprint has decided that /18 (or maybe /17 now) is the right tradeoff. Similar, but not the same, choice. If it was the same, this argument would be over and new providers could continue to spring up without having to wonder how they're going to get their first addresses routed and NSP engineers would know that routing table size, while perhaps a bit larger than they'd wanted, would still be seriously limited in growth compared to the alternatives. I really don't care whether Sprint changes their filter to be at /19, or if RIPE, IANA, et al decide that Sprint really is smarter than they are and that /17 is the correct tradeoff point, but its just 2 bits! Stop claiming technical superiority and just make it work right for everyone simultaneously! We (scruz-net) advertise more addresses than I'd like, but the Internic forced us into that corner. We asked for a big block over a year ago. They gave us a /21. We used it right up and asked for a big block again. They gave us a /20. We argued with them about it, and they refused to budge, so we went ahead and used it up to. Then we asked for a big block again. THAT time they believed us. We got a /16. Had they given us the /16 the first time, we'd have 2 fewer announcements in 204.*, and still not be quite done using it up. But I'm not going to go tell a hundred or more customers (a good number of those 204.* addresses are subnetted into /29 for "small LAN" customers) that, without the benefit of any renumbering tools, they get to change everything around and sit on the phone all day with our tech support staff until it works correctly again. -mattthew kaufman matthew@scruz.net