| So how is this supposed to work? For instance, I get a /27 and an AS | number, and I want to multihome. But nobody will listen to my | announcements. This is not a workable solution. So you call up noc@foobar.net and offer them $x to listen to and propagate your announcement, and perhaps to act as your agent in transactions with other networks around the world. Or, you could negotiate 1-on-1 with every network who doesn't give you free (or agent-negotiated) access by default. This imposes cost on you because you are consuming an AS number and introducing an unaggregated and unaggregatable prefix into these networks' routing systems. | Multihomers generally announce just a single route and there are less than | 25k AS numbers so the majority of routes is NOT from multihomers so it | seems somewhat harsh to effectively forbid multihoming. Not all multihoming requires the introduction of unaggregated and unaggregatable prefixes. | Is there really no way | we can all agree on a filtering policy that keeps the routing table in | check but still leaves some room for responsible multihoming? Given the vehemence with which some people argue that filtering is a bad idea in the first place, the answer is clearly "no". A better question is, can tools and information be put together to mitigate the problems multihomers may face as network operators try to deal with expanding tables, in the _absence_ of interprovider cooperation? Sean.
Also sprach Sean M. Doran
So you call up noc@foobar.net and offer them $x to listen to and propagate your announcement, and perhaps to act as your agent in transactions with other networks around the world.
Oh, and that scales really well.</sarcasm> Let's frame a few things first. While IP address depletion is still an issue, its not the major issue at the current time. CIDR is a pretty decent "fix" for that currently, and functions, regardless of how the filtering issue is decided. So, with that tossed to the side for the moment, let's look at the other major issue. Routing table size. I think we're all in agreement that this is the critical current problem that filtering is supposed to fix. Ultimately, the problem here is the RIR policies. IgLou has 6 prefixes that we announce (I know, small time in the overall scheme of things, but bear with me here). I aggregate as much as possible given the 6 prefixes that I have been allocated. IgLou was just allocated our 6th prefix within the past year or so. No provisions were made for us to be able to keep the number of advertisements even the same, let alone lower that. (I know, 6 prefixes isn't a huge deal in the overall scheme of routing table size...I'm talking about conceptually here) I would think it is reasonable, and I believe there has even been verbiage in some of the RIR policy documents at times that new allocations be done in manners to minimize the number of announcements. While I'm not really keen on renumbering equipment on my network, I'm perfectly willing to do so for "the good of the Internet". I think it would be a good idea for RIR's to have renumbering out of un-aggregateable space as a condition on getting more IP space. Set a time limit of a year or two, maybe dependant on the size of the block. It would not be terribly difficult for IgLou to get down to 2 announcements from the 6 we currently have, and its conceivable that we could get down to a single one. Maybe this should happen over time...each time you get a new block, you turn in 2. It doesn't matter the length of the prefix you turn in, since the critical issue isn't the number of IP addresses in use, but rather the number of entries in the routing table. I could *EASILY* renumber out of one of the prefixes that I have (a /24), in a heartbeat, but I have absolutely no incentive to do so...indeed, I have something of a disincentive since that's a loss of available IP space for me, with no benefit. Keep in mind that the number of available IP addresses isn't a significant issue as CIDR is still functional in this sort of environment, so the current RIR policies about utilization of space could still be used with only some minor tweaks. (Obviously, there's no point in giving IgLou a /20 if one of the blocks that I would be turning in would be a /20). This addresses the heart of the current problem, the number of un-aggregateable prefixes, without going back to the original problem from back in the day of depletion of IP address space. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
--On Tuesday, 02 October, 2001 6:33 PM -0400 Jeff Mcadams <jeffm@iglou.com> wrote:
I could *EASILY* renumber out of one of the prefixes that I have (a /24), in a heartbeat, but I have absolutely no incentive to do so
Those who propose filtering a la Verio / Sprint(passim) suggest that your incentive to renumber is that certain other (not in the line of transit) networks will not accept these prefixes (or apply more stringent dampening on them), and hence give you inferior routing either permanently (filtering) or temporarilly (dampening), assuming you have a covering netblock. Of course if you have a swamp /24, the filtering argument doesn't apply, but the dampening one does. Aside: It's interesting that all the anti-filtering arguments are coming from those who are customers of Filterer's peers. We have heard that Filterer doesn't filter its own customers, but we haven't heard Filterer's BGP customers complaining (at least in this forum) that they are missing routes and hence have suboptimal connectivity to Filterer's peers' customers. As last 3 letters of NANOG indicate, we here should perhaps be interested in designing filtering policies which attract happy paying customers - so far few people have suggested an upstream with aggressive peer filtering is a worse upstream. (Ducks from torrent of mail) -- Alex Bligh Personal Capacity
Also sprach Alex Bligh
Those who propose filtering a la Verio / Sprint(passim) suggest that your incentive to renumber is that certain other (not in the line of transit) networks will not accept these prefixes (or apply more stringent dampening on them), and hence give you inferior routing either permanently (filtering) or temporarilly (dampening), assuming you have a covering netblock.
But that's not an incentive to renumber at all, because I can't go to ARIN and say, "I want to renumber out of these disparate blocks and get one big one that is more globally routable." So renumbering out of the block that I'm thinking of (204.252.74/24, FWIW) still doesn't do me any good.
Of course if you have a swamp /24, the filtering argument doesn't apply, but the dampening one does.
The /24 I mentioned above isn't swampy, but I do have a swamp /24 that we make use of...and it would be one of the more difficult ones for us to renumber out of, but we'd be willing to do for "the good of the Internet" if we weren't going to be stabbed in the back for doing it, which is about the situation as it exists now.
Aside: It's interesting that all the anti-filtering arguments are coming from those who are customers of Filterer's peers. We have heard that Filterer doesn't filter its own customers, but we haven't heard Filterer's BGP customers complaining (at least in this forum) that they are missing routes and hence have suboptimal connectivity to Filterer's peers' customers. As last 3 letters of NANOG indicate, we here should perhaps be interested in designing filtering policies which attract happy paying customers - so far few people have suggested an upstream with aggressive peer filtering is a worse upstream. (Ducks from torrent of mail)
Perhaps that's because all of us that think the filtering is a bad thing wouldn't touch a Filterer's network with a 39 1/2 foot pole. I think its rather a self-selecting sample. Personally, I look forward to the day that a Verio sales rep. calls me trying to sell me transit so I can read him the riot act about their filtering policies. Ultimately, the policies in place for IP allocation *encourage* routing table growth. We can blame Verio, or whoever is filtering, and I believe they do deserve all the flames they get...probably more...as they choose to filter and essentially say, "Screw you, little providers and small corporations, you're not a big boy so you don't deserve robust network connectivity." I do have to reserve some blame for the RIR's as well though. Their policies encourage routing table growth, so they have to share in the blame for that. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Jeff,
Those who propose filtering a la Verio / Sprint(passim) suggest that your incentive to renumber is that certain other (not in the line of transit) networks will not accept these prefixes (or apply more stringent dampening on them), and hence give you inferior routing either permanently (filtering) or temporarilly (dampening), assuming you have a covering netblock.
But that's not an incentive to renumber at all, because I can't go to ARIN and say, "I want to renumber out of these disparate blocks and get one big one that is more globally routable." So renumbering out of the block that I'm thinking of (204.252.74/24, FWIW) still doesn't do me any good.
Well, I'm more familiar with RIPE than ARIN, but if you are saying 'If I were to apply for a /x anew, ARIN would give it to me, but as I already have a /a, a /b, a /c, ARIN won't let me return them, and renumber into a /x' I'd suggest that policy needs looking at, for exactly the reasons you suggest. I /do/ know of instances where companies have (say) an old /16, severely underutilized, and want to get more space for some reason, offer to return their old space, but insist on getting at least a /19 (or similar) on the grounds of routability, even though if they made the application afresh they'd get at most (say) a /22. Hard one to call that. -- Alex Bligh Personal Capacity
Date: Tue, 02 Oct 2001 23:48:55 +0100 From: Alex Bligh <alex@alex.org.uk>
[ snip ]
Aside: It's interesting that all the anti-filtering arguments are coming from those who are customers of Filterer's peers. We
[ snip ] Perhaps those who disagree with this type of filtering avoid the upstreams in question? If customer of Filterer understands what's happening, and doesn't mind losing redundant paths to smaller networks, _that's_ what I want to hear. AFAIK, that hasn't been posted, either. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (4)
-
Alex Bligh -
E.B. Dreger -
Jeff Mcadams -
smd＠clock.org