- NANOG - lists.nanog.org

Re: Has PSI been assigned network 1?
by sob＠academ.com 01 May '95

01 May '95

Okey. I am just looking for clarification. Vadim's statement seemed to either indicate that ANS was not a "large service provider" or that NSSes were no longer part of ANS's backbone. I am certainly in no position to know how to classify "large service provider" unless we look at the NSF NSP definition as a metric. If there is another objective definition, I'd be happy to hear about it. As for the NSSes no longer being in the ANS backbone, it is clear that ANS is using some Cisco products, but it is also clear there are still some CNSSes that Cisco didn't build. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

2 1

Re: May COOK Report Published tonight (fwd)
by rcollet＠sprint.net 01 May '95

01 May '95

Mike: there are no plans to do anything at this time! Please don't read more into this exploratory initiative than that we are examining the environment with respect to membership needs. The White Paper looks at both being a registry and utilizing existing registries, e.g. InterNIC. We obviously need to be complimentary with existing and future endeavors. Thanks Bob Collet >I wonder how many of you have heard about the CIX plans to become THE >Internet routing arbiter and in other ways replace the former NSFNet? >Is there any serious possibility of their plans coming to fruition? > >---------- Forwarded message ---------- >Date: Sun, 30 Apr 1995 22:19:06 -0400 (EDT) >From: Gordon Cook <gcook(a)tigger.jvnc.net> >To: inet-access(a)earth.com >Subject: May COOK Report Published tonight > >Apologies for the empty post! > > >CIX Reorganization. pp. 1-7 > >We publish an interview with CIX Association President Bob Collet. >In January the CIX appointed Susan Fitzgerald as its new Executive >Director. Given the uncertain situation of the CIX, Susan's position >is part time while she continues to run her network consulting >company. Nevertheless Collet and Fitzgerald have been hard at >work on a strategic plan and telecom white paper designed to turn >the CIX into a trade association. While the CIX is still running its >router and filtering has just gone into effect, the environment of >the Internet has been so totally transformed since last summer >that that the interconnect and peering services offered by the CIX >router have become essentially meaningless with the opening of >the NAPs and MAE West and the expansion of MAE-East. > >However, the change in network topology has done interesting >things to the cost of directly connecting to the core Internet. A >year ago this could be done via a connection at the CIX router for >perhaps $40,000 a year for the membership, connect fee and T-1 >transit to the router. Now connection at T-3 speeds to multiple >NAPs is necessary at a base cost that we estimate to be about >$400,000 a year. > >The CIX task force that was recruited when Collet became >President late last November has turned its attention to such tasks >as the definition of lobbying positions before the FCC in an effort to >keep a level field for ISPs faced with the entry of RBOCs into their >markets. In its Strategic Plan it has also outlined a new >infrastructure model of High Bandwidth Packet Exchange Points >(HPEPs), First Tier Providers, Large ISPs and Third Tier Prodivers >which may aggregate their traffic in Packet Exchange Points before >being sent on the HPEPs. One of the possible roles posited for the >CIX is providing the basic language of interconnect agreements >between the various levels of the new infrastructure. Running a >routing registry for members is another possible service for >members that is discussed. > >While press accounts list 155 members Susan Fitzgerald told us >that the current count is actually 145. She said this figured is >taken from the total number of networks that had ever joined the >CIX, including the large number that signed up last fall paying a >partial year's fee in order to be able to attend the Atlanta >membership meeting. Critical to the CIX's future will be the >number who pay 1995 dues. Because the first thing that Fitzgerald >had to do was reorganize the CIX's books, invoices for 1995 dues >were not even sent out until February. Members will have until >June 1 to pay up in order to attend the membership meeting at I- >Net in Hawaii later that month. The Strategic Plan and Telecom >White Paper were sent to memebrs on March 30, with the hope >that they would give members sufficient reason to renew. With >only a single tier of dues set at $7500 a year, our guess is that the >number of members at the June meeting will be much diminished >from the current 145 total. Last week NYSERnet announced that it >would not be renewing its CIX membership - not a good sign for >the future viability of the CIX. > >While there is nothing about the program that Collet has put >together that looks especially negative to us, there are parts of the >infrastructure model design that may not be well received by all >quarters. More important however is the question of >communication with the network community at large. If the CIX is >ever again to speak for the preponderance of the commercial >internet, those on its Board must take the organization's new >program before the internet community as a whole and argue >openly for its support. The fact that we have not seen this happen >combined with an increasingly active role by an Internet Society >showing signs of wanting to move into the vacuum created by the >end of the NSFnet, is not a sign that bodes well for the CIX's future. > >ISOC, Network >Infrastructure, IETF & NAPs pp.1, 8 -9 > >Who will put money into commercial domain name registration >and into the IETF is a current critical topic among Internet policy >makers. We state some NSF assumptions on these issues, publish >responses from ISOC Director Tony Rutkowskii and describe the >decision taken by the Federal Networking Council to continue >supporting IETF to the tune of nearly 1.5 million a year in order to >be certain that IETF maintains its independence. Updates on >PacBell and Ameritech NAPs - including a PacBell communications >slip. > >MCI May Impose Metered Pricing pp. 10 - 11 > >MCI's John Houser side stepped our questions after New >Hampshire ISP asserted that his MCI sales reps had said metered >pricing would begin some time in May. > >Routing in the Post NSFnet World, pp. 12-16 > >The MERIT Policy Routing Data Base is being replaced by the >Routing Arbiter Database and Route Servers. But in the new >decentralized multiple backbone world we have just enetered, not >everyone has committed to use the Routing Arbiter. This >combined with heavy pressure on Sprint's routers, caused Sprint to >begin to restrict the portability of some CIDR blocks for routing >purposes. After a heavy flame war between Sprint, PSI and >MCSnet, the likely out come will be to restrict greatly the >portability of IP numbers obtained via CIDR blocs should a >customer using those numbers decide to change providers. > >Access Indiana Revisited, pp. 17-20 > >The award of the state preferred provider contract has been >delayed until late May. In the meantime it has become clear that a >centralized head end, top down model into which all community >networks will be plugged is intended. A 12 county private sector >effort to link K-12 schools was polity told to stand aside in early >April since it would be duplicating the centralized effort of state >government. When a private ISP offered to extend service into a >rural community, she was also rebuffed. Ameritech, State Dept of >Education and State Library money is going not into community >owned infrastructure but rather should go according to organizer >Ed Tully into professional web page design so that Indiana >communities will have attractive content to give a state choosen >central provider. When many communities said they had adequate >talent to design their own Web pages, Tully sharply disagreed. > >Washington State Porn Bill pp. 21-22 > >Under this grossly misguided legislation now on Governor Mark >Lowry's desk, ISPs would be liable to the tune of $5000 a day and >one year in jail for each instance of pornographic material found on >their systems by minors. The legislation would effectively force >ISPs to deny access to minors. > > > >******************************************************************** >Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 >The COOK Report on Internet -> NREN Non Profit. $150 >431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 >(609) 882-2572 Corporate $350 >Internet: cook(a)cookreport.com Corporate. Site Lic $650 >http://www.netaxs.com/~cook <- Subscription Info & COOK Report Index >********************************************************************

1 0

Re: Has PSI been assigned network 1?
by sob＠academ.com 01 May '95

01 May '95

Vadim, I thought that ANS was still using CNSSes and ENSSes, which I don't believe that Cisco built. Please let me know if I have misunderstood your statement here. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

3 3

Re: BGP vs. static routing (Re: Why Vadim likes statics)
by Robert E. Seastrom 30 Apr '95

30 Apr '95

Sue: Lots of companies require electricity and phone service in order to conduct their business. Given the comparatively small number of companies that have phone lines served by more than one central office or redundant power feeds to their buildings (much less lines provided by more than one phone company or more than one power company), I little evidence to suggest that there will be a huge growth in the number of multi-homed networks in the near future. Your last paragraph is most telling, however. We are looking at this situation from two different angles. While you are designing the next generation of routing protocols, my compatriots and I are discussing how to reasonably configure the hardware we've already got with existing protocols in order to keep the poor CPUs in boxes that carry full routing from melting down due to route flap. Neither task is inherently better or more honorable than the other, but it is important to not let the purposes become crossed. When the futurists are permitted to interfere with the here-and-now pragmatists, what happens is called OSI. When you let the here-and-now pragmatists interfere with the vision of the futurists, you get the phone company and cable TV. I am quite interested to see a copy of your paper; please send it (or a pointer) along. IDRP may be wonderful, but it is not likely to make the CPUs in ICM's routers sit down and take a rest in the near term. Pull-up routes to reduce flap are a cheap, easy-to-install, and rapidly deployable (though not technologically beautiful) way to do that, and should be deployed with all reasonable haste (in my biased opinion). Best regards, ---Rob > Rob: > > During the Development of the IDRP specification, there we > discussion about how to automatically generate from the IGP > information, the information necessary to send in BGP/IDRP. Have you > read the paper by Yakov, Dave Oran, and myself on this? It was written > a while ago. I can send you a copy. > > The single core corporate, with single homed may be currently a > winner - due to security and ease of access. However, it may be that > the future, will require more redundancy for certain businesses who > use the Internet to sell services. > > At that point multi-homed corporate networks may grow out of the 5%. > The multi-homed network prefixes, could be generated form IGP > information. > > Please don't take this as a should, but a thoughtful response on > what "might" be. > > Best wishes, > > Sue Hares > >

1 0

Re: Has PSI been assigned network 1?
by Vadim Antonov 30 Apr '95

30 Apr '95

> You were saying that Cisco's "state of the art" equipment was inadequate to > handle the load you were presenting to it, in that the slightest abnormality > in the external world made it essentially useless for a period of time. Yes. But not because of CPU switching packets. >My argument is that one of three things must then be true: >1) You are incorrectly using the equipment you purchased. Please teach us on how to use it correctly. Ypu have the full information on the toplogy of SprintLink and the Internet at large. >2) The equipment is not meeting its specifications which you relied on > when you purchased it. That is certainly not the case, for we are beta-testers for cisco. We do not rely on the marketing literature; and cisco is being very cooperative in providing large ISPs with the access to the people in company who actually know how the thing works. >3) The equipment is incapable of handling the load presented by a > "modern" Internet. It is barely capable. The fact is it is the only equipment today which is capable of handling the load and has appropriate functionality (i.e. actually works). Which explains why *all* large service providers use ciscos as backbone routers. We're investigating the alternative vendors' products, too. The only interesting thing available now on the market is highly specialized, unfortunately. --vadim

2 1

Re: Has PSI been assigned network 1?
by Sean Doran 30 Apr '95

30 Apr '95

They also keep asking me who might be interested in a number of them at cut-rate prices (slightly used). I could always point them at you. Sean.

1 0

Re: Has PSI been assigned network 1?
by Sean Doran 30 Apr '95

30 Apr '95

Actually, Tony, people at Advantis keep calling me and asking if we'd be interested in picking up a bunch of NSSes on the cheap. Sean.

2 1

Re: Has PSI been assigned network 1?
by Vadim Antonov 30 Apr '95

30 Apr '95

FYI -- Sprint never submitted NACRs on behalf of customers, for purely legal reasons. As common carrier Sprint is legally prohibited from enforcing anything related to contents of communications, hence it couldn't enter legal agreements on AUP-compliance in regard to customer traffic. So, we HAVE to pass thru all NACRs (and don't forget that 1800 has most of Europe to care about). --vadim >From sjr(a)merit.edu Thu Apr 20 02:14:32 1995 Received: from tiny.sprintlink.net (tiny.sprintlink.net [199.0.55.90]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA22156 for <avg(a)titan.sprintlink.net>; Thu, 20 Apr 1995 02:14:31 -0400 Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by tiny.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA22402 for <avg(a)sprint.net>; Thu, 20 Apr 1995 02:14:29 -0400 Received: from localhost (sjr@localhost) by home.merit.edu (8.6.12/merit-2.0) with SMTP id CAA21817; Thu, 20 Apr 1995 02:14:26 -0400 Message-Id: <199504200614.CAA21817(a)home.merit.edu> To: Vadim Antonov <avg(a)sprint.net> cc: HANK(a)taunivm.tau.ac.il, curtis(a)ans.net, guy(a)ghost.uunet.ca, jerry(a)fc.net, nanog(a)merit.edu, prs(a)isi.edu Subject: Re: Has PSI been assigned network 1? In-reply-to: Your message of Wed, 19 Apr 1995 18:49:39 EDT. <199504192249.SAA20468(a)titan.sprintlink.net> Date: Thu, 20 Apr 1995 02:14:25 -0400 From: "Steven J. Richardson" <sjr(a)merit.edu> Status: R Vadim: > Date: Wed, 19 Apr 1995 18:49:39 -0400 > From: Vadim Antonov <avg(a)sprint.net> > To: HANK(a)taunivm.tau.ac.il, avg(a)sprint.net, curtis(a)ans.net, guy(a)ghost.uu net.ca, jerry(a)fc.net > CC: nanog(a)merit.edu, prs(a)isi.edu > Hank Nussbacher <HANK(a)taunivm.tau.ac.il> wrote: > > >The e-mail interface > >of NACRs is close to uselessness, and too big headache to deal with. > >Waiting time on processing is simply ridiculous. > > >I've been sending updates to auto-dbm(a)ripe.net for the past 2 years > >with no problem. > > You don't have to keep a full-time engineer just to handle > NACRs, do you? Please be fair; most of this is a problem which Sprint brought on itself through poor follow-through with an allocation policy which you and I discussed on the phone a quite a while ago. To be clear about what is going on, let's review the history. I called you a long time ago (about a 1.5 years ago) and mentioned that it would be a lot easier on your NACR person (the pre-Lisa-Carlson person, as I remember) if you would: - decide on a consistent (net announcement ["aslist"] + AUP) for some large aggregates of IP address space, - register (NACR) those aggregates, - sit back and assign customers of like policy out of these pre-existing aggregates. Note that these customers would NOT require a NACR. You agreed and set up three /16 aggregates of what had been Class-C IP address space. From that time on, there has been a "drift" in policy away from the aggregate policy, which shows that the procedure for assigning nets from Sprint-controlled IP address aggregates was somehow ignoring what you set up. If your lead had been following by whatever internal procedures Sprint uses, then there would have been no need to NACR any customers who had policy which matched one of those aggregates. When new interconnection points were added, the aggregate's policies could have been updated, automagically updating the policy of all of the members of the aggregates. Currently, the state of Sprint policy is shown by the fact that, out of 118 "/16" aggregates, for instance, there are 2580 included prefixes which have policy which does NOT match that of the aggregates. Here's the profile: 188 "/16" Sprint aggregates have 26 different policies among themselves. These 188 aggregates include 2580 more-specific prefixes which have their own policies which differ from the /16 prefix of which they are a part. Of these 2580 prefixes, 2255 (87.4%) are completely due to Sprint (i.e., they are not caused by prefixes which have moved to have a primary AS which is not 1239, 1240, or 1800). These 2255 prefixes are contained within 65 of the "/16" aggregates (34.6% of the 188 total "/16" aggregates). Of these 65 large aggregates: 21 have 1 different policy 15 have 2 different policies 8 have 3 different policies 8 have 4 different policies 6 have 5 different policies 4 have 6 different policies 1 has 7 different policies 1 has 8 different policies 1 has 9 different policies If you sort all of these policies, you find that they can be summarized as follows: Number of: ----------------------------- more-specific "/16" aggs prefixes with in which they policy diffs are found Net announcement policy ----------------------------------------------------------------------------- 24 4 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 253 20 1:1239(144) 2:1800 185 19 1:1239(144) 2:1800 3:1239(218) 2 1 1:1239(144) 2:1800 3:1239(218) 4:210 5:209 2 2 1:1239(144) 2:1800 3:1239(218) 4:3561(11) 5:3561(218) 6:685 7:73 8:101 1 1 1:1239(144) 2:1800 3:1239(218) 4:3561(218) 5:93 22 4 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 3 1 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 5:701 10 4 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5 4 1:1239(218) 2:1239(144) 3:1800 35 6 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 149 18 1:1239(218) 2:1800 3:1239(144) 2 1 1:1239(218) 2:1800 3:1239(144) 4:3561(218) 4 2 1:1239(218) 2:1800 3:1239(144) 4:3830 3 1 1:1240 2:1800 3:1239 12 1 1:1800 130 6 1:1800 2:1133 3:1239(144) 1 1 1:1800 2:1133 3:1239(144) 4:1674 942 32 1:1800 2:1239(144) 20 1 1:1800 2:1239(144) 3:1133 16 4 1:1800 2:1239(144) 3:1133 4:1674 189 20 1:1800 2:1239(144) 3:1239(218) 1 1 1:1800 2:1239(144) 3:1239(218) 4:701(147) 5:701(134) 5 1 1:1800 2:1239(144) 3:1740(135) 1 1 1:1800 2:1239(144) 3:2149 4:174 122 15 1:1800 2:1239(218) 3:1239(144) 1 1 1:1800 2:1239(218) 3:1239(144) 4:1321 1 1 1:1800 2:1240 28 4 1:1800 2:1240 3:1133 4:1674 70 4 1:1800 2:1879 3:1133 4:1239(144) 3 1 1:1800 2:297(145) 3:297(144) 4:372 5:1133 6:1239(144) 6 1 1:1800 2:701(147) 3:701(134) 6 1 1:1800 2:701(147) 3:701(134) 4:1239(144) 5:1133 6:1674 1 1 2:1800 3:1239(218) ============================================================================= 2255 -- 34 different policies SO--by using 34 different policies, you could cover all of the more-specific; in fact, there are only 46 different Sprint-primary policies altogether (i.e., including the policies of the "/16" aggregates): 24 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 253 1:1239(144) 2:1800 196 1:1239(144) 2:1800 3:1239(218) 4 1:1239(144) 2:1800 3:1239(218) 4:209 5:210 3 1:1239(144) 2:1800 3:1239(218) 4:210 5:209 1 1:1239(144) 2:1800 3:1239(218) 4:297(144) 2 1:1239(144) 2:1800 3:1239(218) 4:3561(11) 5:3561(218) 6:685 7:73 8:101 1 1:1239(144) 2:1800 3:1239(218) 4:3561(218) 5:93 23 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 3 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 5:701 11 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 3 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 5 1:1239(218) 2:1239(144) 3:1800 35 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 5 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 5:3561(27) 6:3561(218) 7:93 170 1:1239(218) 2:1800 3:1239(144) 2 1:1239(218) 2:1800 3:1239(144) 4:3561(218) 4 1:1239(218) 2:1800 3:1239(144) 4:3830 3 1:1240 2:1800 3:1239 12 1:1800 138 1:1800 2:1133 3:1239(144) 1 1:1800 2:1133 3:1239(144) 4:1674 1 1:1800 2:1133 3:1239(144) 4:1849 5:3561(218) 6:3561(11) 1 1:1800 2:1133 3:1239(144) 4:3561(218) 5:3561(11) 1 1:1800 2:1133 3:1674 944 1:1800 2:1239(144) 23 1:1800 2:1239(144) 3:1133 25 1:1800 2:1239(144) 3:1133 4:1674 205 1:1800 2:1239(144) 3:1239(218) 1 1:1800 2:1239(144) 3:1239(218) 4:1325 11 1:1800 2:1239(144) 3:1239(218) 4:209 5:210 2 1:1800 2:1239(144) 3:1239(218) 4:210 5:209 2 1:1800 2:1239(144) 3:1239(218) 4:3354 1 1:1800 2:1239(144) 3:1239(218) 4:701(147) 5:701(134) 5 1:1800 2:1239(144) 3:1740(135) 1 1:1800 2:1239(144) 3:2149 4:174 1 1:1800 2:1239(144) 3:3354 124 1:1800 2:1239(218) 3:1239(144) 2 1:1800 2:1239(218) 3:1239(144) 4:1321 1 1:1800 2:1240 28 1:1800 2:1240 3:1133 4:1674 76 1:1800 2:1879 3:1133 4:1239(144) 3 1:1800 2:297(145) 3:297(144) 4:372 5:1133 6:1239(144) 6 1:1800 2:701(147) 3:701(134) 6 1:1800 2:701(147) 3:701(134) 4:1239(144) 5:1133 6:1674 1 2:1800 3:1239(218) Without analyzing the size of the IP address space consumed--which is important, to be sure--I will assume that the 118 /16s could easily hold all of the customers of each of the 46 policies. That means that Sprint has actually submitted *at least* 2255 *extra* NACRs (not including changes and deletes) which certainly is a bit of work if you do it by hand. Of course, there are some NSPs (such as BARRNet) which seem to have laid down such policies and kept to them; in fact, it seems to me that we seldom had NACR activity from BARRNet for the past year or so. > --vadim Steve Richardson/Merit

3 3

Re: BGP vs. static routing (Re: Why Vadim likes statics)
by Robert E. Seastrom 30 Apr '95

30 Apr '95

> So it does not make sense for IBM or Sony to run dynamic routing in > their internal networks?!? Well.... it probably doesn't make sense for IBM or Sony to assign a different AS number to each router in their network and speak BGP between them. It's a matter of degree we're talking about here; of course it doesn't make sense to run full routing everywhere, just as it doesn't make sense to manually set up static routes everywhere. The point we're debating is what point along the line it makes most sense to set the slider. Most corporate networks are dendritic; as Vix noted, you run dynamic routing protocols in the center where there are multiple paths, and on hosts on the leaf nets you point default at the first router in the direction of the core and then forget about it (simple arrangements like this tend not to break and mess up your day). Maybe if you're feeling generous you rip a default route into the leaf nets so that if someone gets a new machine that's running evil routed and doesn't know about default routes and such they won't lose. On the other hand, maybe you would consider such a move to be anti-Darwinian and encouraging sloped-forehead, knuckle-dragging behavior. > > The border router does aggregation outbound and points the aggregates > > at Null 0 with a high metric. > > True. > > > This is for cases in which there is no other router participating > > within the customer iBGP mesh, and where there are N (N>=1) > > upstream providers, and where dynamic routing must take place within > > the ISP's routing domain for various reasons (portable dialup > > links, links that are time-sensitive, etc.) > > The assumption in this case is a common egress point. What percentage of the Internet's end-user customers have a single egress point for their networks? At a guess, I'd say 95%. If taking the preemptive step of installing pull-ups for those networks could reduce route flap by 75%, I submit that doing so expeditiously would get out of the woods at least for the time being. This is one of those cases in which the 90% solution is indeed the Right Thing. No, it won't scale if every end-user decides to become multihomed, but I don't see any great rush in that direction and compared to getting custom hacks put into the router code, it is very cost- and-effort-effective. If space to hold the statics in the configuration memory of the routers is an issue, you don't even have to do that -- a PC running BSDI with a trivially- hacked gated and connected to the fddi ring or "utility ethernet" in your POP can dynamically broadcast the pull-ups into your routers via rip or ospf, and would probably be easier to maintain and blow automatically-generated configs into than loading up the statics directly on the routers (at least you'd only have to do it once per POP instead of once per router). ---Rob Robert E. Seastrom -- rs(a)digex.net Network Engineer, Digex International My posting, my opinions, not speaking for the company, etc. etc.

2 1

Re: Has PSI been assigned network 1?
by Vadim Antonov 29 Apr '95

29 Apr '95

> The equipment available today is designed foolishly -- > route update processing and actual packet processing should NEVER be done by > the same CPU -- but it is -- and as such you're dead when this happens. > > Lest anyone believe this, it's bullshit. > > Karl just buys low end gear and then complains because it's not high > end gear. > > Tony >I suppose that a 7000 with a SSP is considered "low end" gear then? >It was *Vadim* who was complaining about CPU usage on your boxes, not me. >Karl Denninger (karl(a)MCS.Net) Would you please refrain from attributing to me the things i did not say? Particularly i never said anything about "actual packet processing by the same CPU" here. I "complained" (heh i do not _complain_, i simply state the facts) about CPU usage by BGP updates. --vadim

4 3