Policy Statement on Address Space Allocations

What's been bothering me is that Sprint is filtering at /19 in 206/8
but just allocated me a /21 out of 206/8. Since my largest customer
is leaning on me to multi-home, and since I view Sprint's filtering as
indicative of what others are likely to do RSN, I begged Sprint to
allocate a block the size of the smallest block they would route if I
had gotten it from another NSP.

Is it unfair to ask Sprint to make allocations based on its own
filtering policies?

When I multihome and Pennsauken is down, will Sprint's filtering cut
me off from access to other Sprint customers via my alternative path?

Ah, a reason why Sprint's filters are self-defeating. You would
be better off leaving sprint now, and going to a different provider. Use
a /21 out of another provider's CIDR block. If at a later date you decide
to multi-home with sprint, sprint's filters only effect small inbound blocks.
Sprint is more than happy to spew little blocks (so much for 'saving the
global Internet').

I've hear of a lot of crazy ideas from other NSP's, but not a peep of
any other NSP following Sprint's lead on filtering. But suppose other
NSP's did decide to start filtering in the future, that's another reason
to get your own CIDR blocks from the InterNIC ASAP. If you hadn't waited
this long, you could have gotten a block in 192/8 - 205/8, and wouldn't
have to worry about Sprint's filtering in 206/8.

Yes, it is perverse that the people most harmed are those that patiently
follow the 'rules.' It is unfortunate that the IANA and NIC policies
seem to be creating a system that encourages people to jump to the front
of the line. But folks, there seems to be nothing to gain, and a lot to
lose by being a good net citizen. You don't get any brownie points for
being a nice guy. You just get ignored.

Sean Donelan writes:

Ah, a reason why Sprint's filters are self-defeating. You would
be better off leaving sprint now, and going to a different provider.

Sean,

Were it not for Sprint, I wouldn't exist.

When I was starting out I had never even seen a cisco (although I'd
been shoving tcp/ip through them for a dozen years). I had no idea
where to buy one or how to configure it. Sprint not only told me what
I needed, they sold it to me at a good price. They configured it for
me. My first lesson in cisco configuration was by telephone at 4 am
one morning from a Sprint engineer, while we waited for techs to do
something with my line.

(I had one of the oddest set of qualifications and non-qualifications
around. I had co-founded the GE corporate tcp/ip network in 1983, but
I was in R&D, and we'd handed that off to MIS. I had run a LAN
segment of 30 or so assorted unix boxes for a dozen years, but I'd
never configured a router more complicated than a Sun with two enet
ports. I was an applications type - distributed OS's and the like.)

When I was a 56k site with 8 dialup lines in my home, and some people
were trying to extract $10K/yr to pay for a CIX router that almost
none of my packets ever came near, Sprint stood with me and the other
tiny providers. (Selling dialup was then a side business generating
less than $10K gross revenue the first year.)

Thanks in part to Sprint, that side business has grown into a network
of four POPs bringing the Internet to NY State's Adirondack region.
There's no fortune to be made here, but there's a living in it. It's
what I wanted to do, and I couldn't have done it without Sprint.

Sean Doran's recent posting about how the Sprints aren't out to squash
us little guys but in fact are dependent on us was remarkably like the
way I used to explain Sprint's position during the CIX filtering war
in summer of '94. In fact, I think he stole those ideas from me :slight_smile:

Sprint is big, and they're busy, and it can be damnably hard to get
their attention (hence my posting), but I'm here because they helped
me when I needed help and backed me politically and operationally when
I needed backing. Out here in the woods, things like that still
matter.

I think there are other solutions to my problem. I personally don't
even want to multihome ... my private line to Sprint has never gone
down, so I'm effectively part of Sprint's network, and last time I
checked, Sprint was multi-homed. My colocated customer is sitting on
Sprint's network ... what more can they want? Me practicing BGP on
them?

Unfortunately, *their* major customer had its weekend trade show a
week ago when a big fiber cut isolated the show from my customer's
server all day. Since the company had gone public the Thursday before
and had bet its farm (and a lot of other peoples') on good press from
the trade show, things were kind of tense, and my customer is in no
mood to be told how they're already multi-homed.

In fact, multi-homing is entirely irrelevant here from a technical point
of view. From a business point of view "multi-homing" may have some
value, but technically it is worthless, *UNLESS* it provides topological
diversity. Of course that's what everyone *EXPECTS* to get from
multihoming but not that many people closely examine it from an
engineering point of view to see if they are really getting what they expect.

It starts at home. Are you going out two separate demarcs? Down two
different streets? Through two different local exchange buildings?
And then on the regional level, are both your providers renting bandwidth
on the same inter-city fibre bundle?

Seems to me that all of this physical topology nitty-gritty needs to be
dealt with openly, at least with ISP customers, and it seems to me that
it is relevant to any Quality-Of-Service metrics that IETF WG's look at.
Remember, TCP/IP networks were *INTENDED* to be able to continue
operations in the event of a war. The software is certainly capable of
this but the physical topology leaves something to be desired.

Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com