October 2001 - Test - lists.nanog.org

Re: Exodus "locking down" customer gear due to bankruptcy?
by JC Dill 03 Oct '01

03 Oct '01

On 06:03 PM 10/1/2001 -0400, Tim Wilde wrote: >Perhaps your sources are confused by changed procedures; in Boston I've >seen signs posted that equipment can no longer be carried in or out via >the lobby area, and must traverse the shipping & receiving area, but no >evidence of customers being prevented from leaving; in fact, I'm pretty >certain that there's no such restriction being enforced. How odd. In Chicago, I had boxes that had been shipped and held in their shipping and receiving which I was forced to take into the lobby for the purpose of unpacking and putting the equipment on carts before I was allowed to take them into the colo and install in our cabinets. The reverse procedure was used to pack up the boxes I was shipping home, I had to take the equipment out of the colo to the lobby and THEN pack it up, IN THE LOBBY. Needless to say, I found this policy a royal pain in the youknowwhat. They claim this is a company-wide policy, but if it is it hasn't been enforced in Seattle (SE2) or in DC (DC2). I have yet to test how they enforce it in Santa Clara (SC4). jc

3 2

Job fair at NANOG 23?
by Pete Kruckenberg 03 Oct '01

03 Oct '01

Seem to be a lot of people looking for jobs, any chance of having a job fair at the next NANOG? Or even a job posting board with a place to match people with companies (in person or just boxes where resumes can be dropped)? On a related note, the group I'm working for is hiring: Opening for experienced network engineer working on large, multi-service research/education network in Utah. State of Utah isn't going out of business or doing lay-offs anytime soon, it's a fun work environment run more like a start-up than a govt agency. Competitive salary and benefits. Job posting is at http://www.med.utah.edu/hr/joblist/jobdetail.cfm?id=10061 application is at http://www.med.utah.edu/hr/webappv1.0.PDF You can email me as well, I work there in the net. eng group. Pete.

1 0

Re: Verio Peering Question
by Paul Vixie 03 Oct '01

03 Oct '01

> > there has to be a limit. > > A limit is needed, but the filtering method in question to me essentially > says this: > > if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat > as much as you want.. we feel this is an acceptable practice. i strongly doubt that the policy was formulated on that basis. it may or may not be equivilent to what you said, but you have not described anyone's (whom i'm aware of) actual motivations with the above formulation. > Yet, if you're a legitimately multihomed customer wants to push out a > single /24 (1 AS, 1 prefix) that is not considered acceptable. actually there's a loophole. nobody filters swamp /24's that i know of, since so much of the oldest salty crusty layers of the internet are built on those. > The only kind of prefix filtering I would want to implement is something > that can accomplish: > > 1. Define threshold, say /20 or /18 or hell even /8. > 3. all prefixes longer than threshold get held until entire tables are > loaded > 3. start looking at the longer prefixes across the entire ipv4 space > starting with the longest and finishing at threshold+1 > 4. if prefixes longer than threshold appear as part of a larger aggregate > block that *originate* from the same AS, drop. > 5. if prefixes longer than threshold originate from a different AS than > the aggregate, accept. i wish you luck in implementing this proposal. i think that folks with multivendor global networks will find it completely impractical, but you can probably pull it off in a regional zebra-based network with no problem. > This way I could get rid of redundant information yet at the same time not > cause any trouble to smaller multihomed customers. I'm not saying that we > should allow /32's to be pushed everywhere either. As you said there has > to be a limit, and /24 seems to be a pretty good one if something along > the lines of the above mentioned filtering algorithm could be used. let's do some math on this. swamp space is more or less 192/8 and 193/8 (though parts of other /8's were also cut up with a pretty fine bladed knife). if every 192.*.*/24 and 193.*.*/24 were advertised, that would be more prefixes than the entire current table shown in tony bates' reports (~100K vs 128K). that is of course just the existing swamp. and it would be hard to handle but even harder to prevent since there's no real way using today's routers to say "accept the current /24's in 192/8 and 193/8 but don't allow new ones". this is the bogey man that gives people like smd nightmares. then there's everything else. if 20 /8's were cut up into /24's then tony bates' report would have 1.3M more things in it than are there today. if the whole IPv4 space were cut up that way then we'd see 16M routes globally. those numbers may seem unreasonable, either because current routers can't hold them, or because current routing protocols would never be able to converge, or because you just can't imagine humanity generating even 1.3M /24's let alone 16M of them. multihoming is a necessary property of a scalable IP economy. actually, provider independence is necessary, multihoming is just a means to that end. if you don't think there are more than 1.3M entities worldwide who would pay a little extra for provider independence, then you don't understand what's happened to *.COM over the last 10 years. in that case i'll simply ask you to take my word for it -- you make 1.3M slots available, they'll fill up. i do not know the actual limit -- that is, where it ends. i know it's going to be higher than 1.3M though. i also know that the limit of humanity's desire for "provider independence without renumbering" (or "multihoming") is currently higher than what the internet's capital plant, including budgetted expansions, can support. and i strongly suspect that this will remain true for the next 5..10 years. > I'm sure in reality there's many reasons this would not be able to be > implemented (CPU load perhaps) but it would atleast do something more than > a "gross hack" that nails some offenders, not all by any means, and > impacts multihomed customers who are only a portion of the problem that > the current prefix filtering solution does not solve. people are out there building networks using available technology. forget about CPU load and look at delta volume and convergence. the "internet backbone" is not fat enough to carry the amount of BGP traffic that it would take to represent the comings and goings of 16M prefixes. 1.3M is probably achievable by the time it comes due for natural causes. do any of our local theorists have an estimate of how much BGP traffic two adjacent core nodes will be exchanging with 1.3M prefixes? is it a full DS3 worth? more? less? every time you change out the capital plant on a single global AS core in order to support some sea change like 10Gb/s sonet or 200K routes, it costs that AS's owner between US$200M and US$1B depending on the density and capacity. bean counters for old line telcos used to want a 20 year payback (depreciation schedule) on investments of that order of magnitude. today a provider is lucky to get five years between core transplants. bringing the period down to two to three years would cause "the internet" to cost more to produce than its "customers" are willing to pay. so in the meanwhile, verio (and others who aren't mentioned in this thread) are using the technology they have in order to maximize the period before their capital plant becomes obsolete. as i said in a previous note, they are certainly balancing their filters so that filtering more would result in too many customer complaints due to unreachability, but filtering less would result in too many customer complaints due to instability. anyone who wants the point of equilibrium to move in the direction of "more routes" should be attacking the economies which give rise to the problem rather than attacking the engineering solutions which are the best current known answer to the problem. in other words go tell cisco/juniper/whomever your cool idea for a new routing protocol / route processing engine / cheap OC768-capable backplane and maybe they'll hire you to build it for them.

4 3

Exodus "locking down" customer gear due to bankruptcy?
by Christopher A. Woodfield 03 Oct '01

03 Oct '01

I've heard anecdotal evidence that Exodus has a clause buried in at least some of their contracts that effectively prohibits the customer from removing their equipment from their facilities in the event of bankruptcy. Not the customer filing Ch. 7/11, but EXODUS going bankrupt. Furthermore, it appears that as they have indeed filed Chapter 11, they are actively enforcing this, at least at their Northern Virginia facility. Has anyone else heard of this or been affected by this? Exodus customers, can any of you look up your contracts and see if you can dig this up? I'm interested in hearing the exact language, if it is indeed a standard clause...I'm thinking there's no way that this could be enforceable, although it would probably take a TRO to get them to let customers claim their gear. -Chris --------------------------- Christopher A. Woodfield rekoil(a)semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

7 11

Gordius has left the building. Was: RE: The Gorgon's Knot.
by Bender, Andrew 03 Oct '01

03 Oct '01

Deepak Jain wrote: > The problem is where the RIB, or forwarding table is exported to > the line cards which frequently have less than 128MB of usable > RAM/SRAM/memory storage/etc. This essentially means that the line > cards can only directly talk to other line cards for a specified, > limited number of routing prefixes. I do not know the algorithms > used when the line card is out of memory, but in many cases this > memory is not field upgradeable beyond a certain point. Srinivasan, Vargese, and others have demonstrated / observed that space is not a material problem for the architecture you describe. Rather, it is the time to complete a longest-match (or equivalent) operation for each forwarding event, especially for high(er) interface speeds. Regardless, 128MB is a LOT of table memory, especially when it is virtually unknown to see anything larger than 10-20Mbit CAMs; prior to reduction / expansion / etc, there's scarcely 11B of unique information in an IPv4 route. Adding in some bytes for mysterious 'other stuff', this is easily 4-8MM routes. We'll have to see another knee in route proliferation before this becomes a problem, and space exhaust would most certainly prevent this from happening. > Many smaller networks can and do use PCs for BGP and for > forwarding because their total forwarding needs at their core are > say sufficiently less than 800mb/s upto which PCs seem to handle. > However, the desires and models of these smaller networks don't > scale much beyond this level with currently available PC > technology. Agreed... as regards PCs lets remember that history has offered certain commentary on the non-role of PCs (indeed general purpose computers) in network infrastructure... viz. there aren't many GRFs / DDP516Rs / etc. around anymore. I doubt this is an 'interesting problem' for the op or planning community. Regards, Andrew Bender taqua.com

2 1

RE: Verio Peering Question
by smd＠clock.org 03 Oct '01

03 Oct '01

| 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(a)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.

4 5

Re: Verio Peering Question
by smd＠clock.org 02 Oct '01

02 Oct '01

| Oh, and that scales really well.</sarcasm> The solution to this is very simple: aggregate. Sean.

3 2

route-server.cerf.net
by Dan Hollis 02 Oct '01

02 Oct '01

Looks like its broken? -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

3 3

RE: Verio Peering Question
by smd＠clock.org 02 Oct '01

02 Oct '01

| While I certainly support the idea of usable micro allocations, and have | voiced my support on various ARIN mailing lists for it, it should be | remembered that the same folks who generally espouse restrictive filtering | policies are also those who voice the greatest opposition to a realistic | micro allocation policy. Their argument normally underscores the somewhat | facetious issue of routing table size. In hopes of correcting this somewhat, let me say that not only am I a strong supporter of filtering, I have also suggested fairly seriously to some registry-types that it is fair to allocate individual /32s as necessary to contain address consumption. That is, the registries are correctly focusing on that resource-management, and should spend energies on reclaiming wasted space (hello MIT!) rather than on managing multiple scarce resources. ISPs can and will filter or otherwise penalize users of long and/or flappy prefixes as dynamicism forces them to do so. Since filtering can become REALLY aggressive if and as necessary, nobody should worry that ISPs will be so overwhelmed that the RIRs have to help out with this problem. | Ad hominem attacks against individuals [are bad] But but it's open season on "folks" who make "facetious" arguments? Sean.

5 4

Traffic Shape or Rate Limit
by Christopher J. Wolff 02 Oct '01

02 Oct '01

Hello, I'm wondering what the list's opinions are on Traffic-Shaping vs. Rate-Limit for DIA customers (Frac DS3, for example). From what I've read, Traffic Shaping is a better option since it doesn't drop packets. Just curious as to what the opinions are. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com email:chris@bblabs.com phone:520.622.4338 x234

8 10