|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: The Gorgon's Knot. Was: Re: Verio Peering Question
On Fri, 28 Sep 2001, E.B. Dreger wrote: > > I think we should encourage people to introduce individual /32s > > into the network and flap them around a bit, to force some > I've not seen anyone suggest allowing longer than /24 in this > thread. However, I'll definitely admit that, with name-based > hosting, some webhosts most certainly could want to announce long > prefixes. Filtering on prefix size is a pretty absurd idea. A network is not automatically unimportant because it has few addresses. A.ROOT-SERVERS.NET has a single address and www.cnn.com several within something that could be a /25 and a /27. I sure want to be able to reach those as effeciently and reliably as possible. Why should they announce 4000 extra unused addresses just to avoid filtering? On the other hand, filterers do have a point: why are there so many /24s in the global routing table? But then again, this also happens to a lesser degree for larger blocks. Have a look at the 24.x.y.z space, this is pretty ridiculous. Obviously, some networks don't care about the size of the routing table and announce hundreds of routes. Other networks do, and filter the easy targets. (And some networks manage to fall into both categories.) The result being that a group that didn't cause the problem suffers and the problem is not really solved. > 3. Establish guidelines on what is "acceptable" table size, CPU > utilization, etc., and then decide how to get there. I don't think this is going to happen. Even if we can agree on these things _today_, everybody has a different view of what is going to happen in the future and how we should prepare for that. > <conspiracy_theory> > Are big providers so desparate for business that the want to > prevent customers from multihoming, attempting to be the sole > vendor of bandwidth? > </conspiracy_theory> I don't think they are actively doing this, but if filtering is "sound engineering" and it happens to make life harder for a lot of those annoying small compitors, well, they can't help that, can they? > All that said, I _do_ favor IP allocation based on region. Say > I connect to KSCYMO, which connects to CHCGIL or DLLSTX... IP > allocation would be from a sub-ARIN entity in one of those > regions. Make space portable between providers... > Wait a second. All of this sounds vaguely familiar... ;-) The problem with this and many other good ideas is that they can only work well if they are widely adopted. And there are always people who have reasons (legitimate or otherwise) why they want another solution or keep things as they are. But I agree that some form of regional filtering and/or addressing could be beneficial. I live 30 miles from a major interconnect point. I would rather have 30k prefixes up to /24 or even larger that are reachable over this exchange point in my routing table and have a default for the rest of the world, than run full routing but only for RIR assigned blocks. But then, I buy transit so I don't have to be defaultless. But a defaultless network could accept large prefixes at exchange points but keep them local and only propagate RIR block filtered routes throughout the network. This would work better if routes were colored with information about their origin region, though. Even better would be if the RIRs would divvy up the world in 10 - 20 regions, and allocate a /8 - /10 to each. That way, the routers don't have to know all individual routes to some remote region, but they can simply forward the traffic to a part of the network that does know the region-specific routes. If anybody bothers to reply to this, you will see that there are numerous reasons why this isn't "the" solution. However, it may help some people some of the time, and it doesn't impact those who don't want to use it. And, more importantly: it doesn't require universal cooperation. Just the RIR's. Iljitsch van Beijnum
|