At 09:40 PM 9/27/2001 +0100, Alex Bligh wrote:

...

No other network seems to have a problem with the extra announcements. ^^^^^^^^^^^^^^^^ Verio cannot explain why these larger networks can accept small announcements and still run a network as well (or better) than Verio, but Verio insists networks should not accept small announcements.

Many other networks filter, some to the same extent. Few post public policies.

Every network I know filters - on /24s and longer (and one did /25s last time I looked). No network I know filters to the extent Verio does. And *every* network gives hints to their policy - they announce prefixes. Looking in a publicly available route server, I can see /24s from classical A space being accepted from peers in the announcements of the following networks (in no particular order): * UUNET * Sprint * Genuity * Concentric (2828 - 4908 does not appear to give transit) * Above.Net * Exodus * L3 * Qwest * AT&T (both AGNS & 7018) * Teleglobe * GC * EBONE There are other networks out there, but I think this proves that most networks of approximately Verio's size (and all of the networks larger than Verio, methinx) do not filter as Verio does.

Few people are as vocal as Randy about it, and he's moved on from Verio. Given he's still vocal about it, and Verio still filter, either he's a very believable crank, or he has a point, and has been trying to educate you for free. You choose.

I am afraid you have forgotten many, many other possible answers to those two premises. For instance, Randy could be an un-believable crank, and Verio has just not gotten around to un-doing his previous policies? Telcos (especially Japanese telcos) move slowly. As for education, I would like to thank Randy - and you - for all the education I can get. Lord knows I do not know it all (despite what I sound like sometimes :). I simply choose to disagree on this point. And I am not alone - notice the list of networks above. Then again, perhaps every one of them is wrong, while Randy & Verio are right? (Of course, this begs the question why AT&T, where Randy works, and XO, where you work, do not filter as Verio does? Perhaps US telcos move slowly too? :)

...

One can make one's own judgement what this says about Verio's ability to run a network.

I'd be making the judgement once I'd looked at performance and reliability stats. I'd also, as a customer, be keen to look at pricing to the customer, and as an investor or customer interested in long term survival of a supplire, at Capex expended to achieve whatever service level was given. On what would you be basing your judgement?

Good point. Please note Verio's latest financial announcements. They may be owned by NTT, but losing > 3/4 of a billion dollars on less than half of that in revenue does not bode well, even for a company as big as NTT. Also, please note the financial health of other networks which do not filter, e.g. UUNET. Or better yet, how about the financial health of a network who used to filter but does not any longer, e.g. Sprint. Seems to me Verio should stop filtering. As for performance, we can all argue about that forever. I would pick UUNET over Verio, but that's me. I'd ask for a vote, but it would only start an even bigger flame war. Let's just let the performance thing be decided by each person individually.

I don't think anyone has ever claimed (Randy included) that filtering out long prefixes never hurts performance /to those long prefixes/. Just that the usage of those long prefixes is small, the effect is often small, and the NET effect (i.e. on performance to all prefixes) is often improved, AND the 'public good' effect, in terms of encouraging CIDR and discouraging disaggregation has benefits for the global routing table, for everybody, in terms of reduction of cost (nice statistical demonstration at last IETF Ptomaine session - please refer to 'belling the cat' problem).

Are you going to present statistical data to the contrary?

[SNIP] I actually wrote a response to this. However, I doubt you would care. So how about this for a counter argument: You win. All those other network is completely clueless, and every network should filter. Fortunately, I do not run a network any more, so everyone can dismiss me as a crack. (Although I still think it would solve the problem very quickly if everyone filtered *just* Verio. :)

Alex Bligh

-- TTFN, patrick P.S. You never did address why Verio preaches one thing and practices another. Neither has Randy to my knowledge (other than to say "if you are dumb enough to take them" or something like that). Is hypocrisy an official policy at Verio?

On Thu, Sep 27, 2001 at 07:29:01PM -0400, Patrick W. Gilmore wrote:

...

I am afraid you have forgotten many, many other possible answers to those two premises. For instance, Randy could be an un-believable crank, and Verio has just not gotten around to un-doing his previous

At 04:26 PM 9/27/2001 -0400, Dorian Kim wrote: policies? Telcos

...

(especially Japanese telcos) move slowly.

Verio is an ISP, not a telco.

Verio is owned by a telco, but to be honest, I like your definition better. So I will concede the point and apologize for my misstatement.

You make an assumption that other major backbones that don't filter as Verio does think that doing so is a bad idea. That assumption is not necessarily true.

I am sorry, I should not have implied that since many other networks were not doing it then the engineers there believe it is the "Right Thing". Allow me to re-phrase: I submit that every major backbone I can find (except Verio) accepts /24s from their peers in classical A space as proof that most, if not all, backbones of approximately Verio's size, and all backbones larger than Verio, do not filter as Verio does. I suggest that if every engineer, or even a large majority of them, believed strongly that filtering was "The Right Thing", at least some of the other backbones would filter. While I could be wrong, one certainly cannot argue that just because political reasons *could* force engineers to configure networks against their will, that this *did* happen. Barring further evidence, Occam's Razor would, I think, support my view. If you have further evidence, please feel free to educate me. I certainly am not privy to the opinions of as many engineers at major backbones as you, Randy, and Alex are.

I've heard many complaints of Sprint's prefix filtering policy, but never from another major backbone providers. If anything, many thanked Sprint for the public service Sprint provided, and wished they do the same.

I've yet to hear another backbone operator complain about Verio's prefix filtering policy either.

I have heard such complaints, to both. I am sorry you have not. Perhaps the others simply did not wish to challenge you because of your stature in the industry. Perhaps they did not want to start a confrontation. Perhaps like minded people hang out together, so I hear a different view than you do. Whatever the reason, I have heard engineers opine that filtering is not The Right Thing. Not that that proves anything, any more than you not hearing the dissenting opinion proves anything. Either way, I believe the fact the Internet is and has been working for many years without even a significant minority of major backbones filtering show that "not filtering" is at least not the end of the world.

Global routing system is a fragile thing. There are no good existing ways of authenticating and authorising origin of prefixen.

Filtering does not solve this problem, although it may alleviate some symptoms for some failure modes.

This periodically causes suboptimality in Internet's control plane, such as the 128/9 incident. Those networks that filtered as Verio does were not affected internally that incident. Those who didn't suffered.

There are many "good" things which filtering prohibits, such as a large backbone accidentally announcing the wrong prefix, and a small network deaggregating to gain control of its own IP space. I have been involved in this more than once personally, and getting a large backbone (e.g. Verio) to even listen to your complaint that they are announcing your /20 is pathetically difficult, especially when you are not a customer. Getting them to fix it is monumental. I would rather deal with two telcos claiming the other is the problem with my circuit - at least they both admit there is a problem! I also submit that this type of problem happens many orders of magnitude more often than the type you mention.

...

P.S. You never did address why Verio preaches one thing and practices another. Neither has Randy to my knowledge (other than to say "if you are dumb enough to take them" or something like that). Is hypocrisy an official policy at Verio?

It would be nice if people knew history better. It saves people from having to repeat old explanations from old days over and over again.

It would be nice if you did not simply assume people are not aware of the history.

Please see smd's rationale for acl 112 on nanog and other fora archives circa 1996.

I have read Sean's argument, and discussed it with him personally. Stating that your customers pay you so you will accept longer announcements is fine, but neither Sprint nor Verio pays their peers to accept those longer announcements, so they should not propagate them. It is trivial to accept longer announcements from your customers than you pass to your peers. Plus, I maintain is hypocritical to argue that the Internet will collapse if networks do not filter because aggregation is absolutely necessary, while simultaneously accepting and passing longer announcements, whether you are paid to do it or not. Sprint's acceptance of long announcements from customers while filtering them from peers did less to foster aggregation than it did to help Sprint get customers who wanted to announce longer prefixes. (To be honest, I do not think Verio is getting the same advantage, but I could be wrong.) And arguing that since everyone should filter it does not matter what you announce is not an argument, it is a poor rationalization for hypocrisy. Plus the fact that Sprint only filtered (sill filters?) their customers on AS_PATH creates much more danger & instability to the global table than filtering on longer prefixes. Another glaring hypocrisy. ***** ***** Listen, Dorian, you are a bright guy, and so is Randy, and so is Alex. But clued or not, claiming something is "The Right Thing [tm]" does not make it so. Filtering is nice in theory, but it misses some basic requirements of the Internet today. The Internet is a tool, a means to an end. It is no longer a research project by academics, nor is a personal toy of a privileged few who happen to run large backbones. The Internet is where it is today because people pumped billions of dollars into it. (Mostly to get pr0n. :) Many of these people require robust, high performance connectivity to the Internet, which can best be guaranteed through multiple connections to multiple providers. And they are willing to pay for it. Providers who ignore these requirements do so at their peril. If you have a better way for people to get robust, high performance connections, please submit it. I do not think filtering is bad because I had a vision from ghod, I think it is bad because it does not let the people paying for all these nice toys, and pushing all these 100s of Gbps, do what they want to do. Do what they NEED to do if we are to continue having an Internet. You can argue that they want what is bad for them, and you may be right. But I argue that requiring smaller companies and providers to have a single connection will cause them more downtime and worse performance than allowing the global table to fill with the longer announcements. History so far seems to be on my side. The statistics Randy quotes do not prove his case, they merely say growth will be slower, so he can keep up. Many companies believe they can keep up with the faster growth. I suggest that any provider which limits itself enough so it can slow the growth will not have to worry about any type of growth for long....

-dorian

-- TTFN, patrick

On Fri, 28 Sep 2001, Majdi S. Abbas wrote:

Sure, they filter, but they invite THEIR peers to filter them, as well. I don't see any hypocracy in that.

If filtering is "saving the Internet," why not practice what you preach? Its a bit like complaining about poluted rivers, but continuing to dump raw sewage into the river because that's what your customers pay you to do. And saying other water systems can filter the water if they don't like it.

On Fri, 28 Sep 2001, Alex Bligh wrote:

There is much evidence to suggest the free market is good at sorting things like this out. Currently, however, we have misattribution of costs.

SMD suggested this a long time ago, for routes in general (i.e. not just long ones). He's right (at least if measured over a long enough time window :-p )

Yes, this could be interesting. I announce one route to UUNET, but they send me over 800 (not counting transit). So that should generate some income for me... I don't think it would be very hard to identify who should pay, but it might be difficult to decide who should receive the money.

On Tue, 2 Oct 2001, Alex Bligh wrote:

Absolutely, assuming UUnet were willing to peer with you, and at that rate for route exchange. Terms to be negotiated in the free market.

In that case, we already have the system in place. It just turns out that the negotiated rate per prefix is $0. John A. Tamplin jat@jaet.org 770/436-5387 HOME 4116 Manson Ave 770/431-9459 FAX Smyrna, GA 30082-3723

Absolutely, assuming UUnet were willing to peer with you, and at that rate for route exchange. Terms to be negotiated in the free market.

"I am a big ISP, you are a smaller connectivity/access provider. You pay me for requesting traffic through my network." "I am a big ISP, you are a smaller ISP who does mainly hosting. You pay me for sending traffic through my network." I can't wait until the DoJ or the EUCC leaves off M$ enough to investigate the 'free market' of peering and excahnge points. Can't be too long. Peter

At 09:01 AM 9/28/2001 -0700, Majdi S. Abbas wrote:

Sure, they filter, but they invite THEIR peers to filter them, as well. I don't see any hypocracy in that.

Patrick, neither does claiming that such filtering /isn't/ "The Right Thing." And I find your prior argument that filtering is hurting the business of Verio as completely laughable -- clearly the open filtering

I am sorry you do not. How about we agree to disagree? I do, however, agree that all their peers should take them up on their invitation and filter Verio, but only Verio. How much would you like to bet that if every backbone, or even just a few major ones, filtered Verio (and only Verio) as Verio suggests, that Verio would stop filtering and ask them to stop filtering? I would put $1,000 on it right here and now, publicly. (Since you mention my job history below, you know I am not an Internet millionaire, so you know this is not an insignificant amount of money for me.) Then again, I can see from below that you obviously do not understand the implications of this filtering policy. policy

is what made providers such as Priori and Onyx (USA) such a success. Someone with your, shall we say, `colorful' job history should be well aware that engineering policy has little to do with the success or failure of an ISP.

Thank you for your support. At least you did not try to imply that my previous networks died because I could not engineer them properly. But that is not really the issue here.

...

The Internet is where it is today because people pumped billions of dollars into it. (Mostly to get pr0n. :) Many of these people require robust, high performance connectivity to the Internet, which can best be guaranteed through multiple connections to multiple providers. And they are willing to pay for it.

And the people who pumped billions of dollars into it are welcome to protect their assets, their network, and their customers as they choose. I do not yet have the ego required to claim that Verio's--or anyone's equipment is in the public domain.

I was not claiming that.

...

If you have a better way for people to get robust, high performance connections, please submit it. I do not think filtering is bad because I had a vision from ghod, I think it is bad because it does not let the people paying for all these nice toys, and pushing all these 100s of Gbps, do what they want to do. Do what they NEED to do if we are to continue having an Internet.

Doesn't it? Filtering does not prevent these people from doing what they wish. It simply establishes guidelines for how they do it. There is -no difference- between filtering on /25-and-longer and filtering as Verio does. The former modifies behavior by asking that people refrain from announcing anything smaller than a /24. The latter simply filters prefixes based on registry allocation policy.

Actually, there is a difference.

...

You can argue that they want what is bad for them, and you may be right. But I argue that requiring smaller companies and providers to have a single connection will cause them more downtime and worse performance than allowing the global table to fill with the longer announcements.

How does this require that they single-home? I have no idea where this paragraph came from, but in the context of this post, I guess that's not a new feeling.

Please read Randy's documents. They explain it quite clearly. I shall try to summarize. A company or small provider can easily get a /24 from their upstream by simply claiming they want to multi-home, even if they do not need 256 IP addresses. A company or small provider cannot get a /20 from ARIN or RIPE or APNIC by claiming they need to multi-home. The registries only hand out allocations based on IP need, they state quite clearly that you should get smaller allotments from your upstream. So, say I am a small company with 50 or so employees, and I rely very, very heavily on my internal web server for my business. I have a few options: * I can place my server at a colocation house, which would put me completely at the mercy of that colocation house. * I can put my web server here in my office and get a single link to the Internet, which puts me completely at the mercy of that physical line and single provider. * I can multi-home. (Probably the best option would be to put the box at a colocation house like Above.Net which allows me to pull in a line from another provider, while also providing me with all the backup & security of a colocation facility instead of a standard business-class building. But that still requires me to multi-home.) Because of my small need for IP space, none of the IP registries will give me my own /20 (or whatever). However, ARIN will not complain if one of my upstreams SWIPs a /24 to me, even if I do not require an entire /24. I announce that /24 to both my upstreams. If that /24 is filtered by all backbones, my second connection to the Internet is essentially useless, a waste of money. Also, please note that if all backbones filtered Verio - and only Verio - as Verio suggests, then anyone announcing a /24 into Verio from the space of another provider would be wasting their money. If the link to the other provider were to fail, the customer would receive no traffic from anywhere on the Internet, except Verio and Verio customers. While this is not a trivial amount of the Internet, it is still a small fraction of the Internet. (This is why I believe Verio would stop filtering if everyone filtered only Verio.) Do you now understand why "filtering == forcing small providers / businesses to single home"? If anything was not clear, please contact me off list and I shall try to explain further. Again, I and many other people are open to alternatives. Whenever I bring this argument up to Randy (and some others), he tells me that these smaller people do not need to multi-home, or that they are not big enough to matter. Kinda arrogant if you ask me, especially considering some of these people (including Randy) used to do the opposite of what they now preach, back before they were "tier 1" providers. I also submit that these small companies & providers are big enough to matter, at least in aggregate. A large amount of traffic (and money) comes from these types of providers & businesses. If there were not that many of them, it would not make a difference to the global table.

--msa

-- TTFN, patrick

At 09:57 AM 9/28/2001 -0700, Majdi S. Abbas wrote:

If the regional registry's policy is the problem, fix that policy, and I think that you'd find Verio's filters would also change. Randy has stated on more than one occaision (back when he worked for Verio) that he would listen to loose /24's within the proper ranges if the registrys would develop a workable microallocation policy.

And just recently seen on the ARIN-ANNOUNCE list:

Proposal: Establish a micro-assignment policy that would allow entities, using multihoming as justification, to obtain an assignment from ARIN longer than the current minimum assignment size of a /20.

This policy proposal discussion will take place on the public policy mailing list (ppml@arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm

Perhaps this discussion should move to that arena, as it seems that even Verio will bend their filters to fit the RIR policies. -Chris -- \\\|||/// \ Chris Parker - Manager, Development Engineering \ ~ ~ / \ WX *is* Wireless! \ cparker@starnetusa.net | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Without C we would have 'obol', 'basi', and 'pasal'

Perhaps we need to step back for a bit and consider the reasons for inter-provider routing, which does indeed have a purpose other than sparking flame wars on NANOG. For any connection established across the Internet, there are presumably two parties to whom that connection is important (ignoring the obvious counter-examples of spam and the like). In general, each end of the connection is paying somebody (or negotiating peering, or whatever), to let them connect to everybody else. The provider that they're paying then has to make some decisions about how they want to provide that service, whether it's to find the fastest or most direct path possible, to provide the service cheaply, to provide the service reliably, to provide the service in some way that hurts their competitors, or some combination of the above. It is in turn up to the customer whether they want to do business with a provider who operates the way their provider does. In Verio's case, they've apparrently decided that there are advantages to a small routing table, which for them outweigh the advantage of learning the potentially better paths they would get from a less stringent filtering policy. I'm sure we can all endlessly debate whether their reasons for making that decision are good enough, but since those directly affected by it are Verio customers, and I'm not a Verio customer any more, I'm not that interested in worrying about it. Other networks may make different engineering decisions, including deciding that the cost of having a bigger routing table is worth it in order to be able to use more optimal paths. They may decide that offering their customers the best possible path to a destination is something worth doing, even if the network their customer's destination connects to is behind a provider who doesn't feel the same way. As such, an ISP may understand that Verio won't listen to any /24s it advertises in non-swamp space, recognize there's not much they can do about that, but still want to see any routing informaion (including non-swamp /24s) Verio can give them that would help them send data quickly to Verio customers. I really don't see Verio being hypocritical here. Instead, I see Verio making a decision about what they want in their own routing table, but offering routes to other providers in case those other providers want to make a different decision. Those other providers are welcome to filter or accept those routes as they see fit. This seems like a simple case of Verio not forcing its policies on anybody else. -Steve On Fri, 28 Sep 2001, Patrick W. Gilmore wrote:

At 09:57 AM 9/28/2001 -0700, Majdi S. Abbas wrote:

...

Blaming Verio for the RIR's allocation policy simply does not make sense.

Allow me to rephrase this slightly: Blaming the RIRs for Verio's filtering policy simply does not make sense.

There is no reason for the RIRs to change. The system works, and works reasonably well today. Verio's policy, if applied to Verio by Verio's peers, would not work. (At least not from the POV of some multi-homed Verio downstreams.)

Also, if Verio would change their filters if the RIRs changed, then all the arguments about the Internet collapsing are inconsistent. (Unless "workable microallocation policy" means eliminating most of the people who currently have /24s.)

You have already stated publicly you do not understand the implications of filtering. Perhaps you should stop trying to defend that which you do not comprehend?

...

--msa

-- TTFN, patrick

-------------------------------------------------------------------------------- Steve Gibbard scg@gibbard.org

Majdi, You seem to shift the burden of deciding filter policies from providers to RIRs. The problem with this is that the RIR's specifically disavow responsibility for setting filter policies, and generally request that ISPs do not use their allocation policies as filter policies. The RIR's motivations are several - to control routing table size is only one of them. The most important is the desire to conserve IP address space, which presupposes the idea of requiring significant justification. 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. Patrick should be applauded for challenging the heavy-handed orthodoxy of those who support restrictive filtering policies. The vast majority of network and network operators have "voted with their feet" in this regard. Ad hominem attacks against individuals because they have worked for carriers that have not prospered in this economy are suspect, as they tend to tar almost anyone who has had the intestinal fortitude to strike out on one's own and design a network. - Daniel Golding

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Majdi S. Abbas Sent: Friday, September 28, 2001 12:57 PM To: Patrick W. Gilmore Cc: nanog@merit.edu Subject: Re: Verio Peering Question

On Fri, Sep 28, 2001 at 12:31:53PM -0400, Patrick W. Gilmore wrote:

...

Then again, I can see from below that you obviously do not understand the implications of this filtering policy. -snip- Because of my small need for IP space, none of the IP registries will give me my own /20 (or whatever). However, ARIN will not complain if one of my upstreams SWIPs a /24 to me, even if I do not require an entire /24. I announce that /24 to both my upstreams.

If that /24 is filtered by all backbones, my second connection to the Internet is essentially useless, a waste of money. -snip- Do you now understand why "filtering == forcing small providers / businesses to single home"? If anything was not clear, please contact me off list and I shall try to explain further.

Actually, it seems to me that your argument is that ARIN/RIPE/APNIC policy prevents people from multihoming. In the past, when new allocations have been opened or allocation policy has been redefined (say, from /19 to /20), Verio's filters have changed accordingly.

If the regional registry's policy is the problem, fix that policy, and I think that you'd find Verio's filters would also change. Randy has stated on more than one occaision (back when he worked for Verio) that he would listen to loose /24's within the proper ranges if the registrys would develop a workable microallocation policy.

Blaming Verio for the RIR's allocation policy simply does not make sense.

--msa

At 06:17 PM 9/28/2001 +0000, Joseph T. Klein wrote:

Find a way to provide reliable multi homing without massive route table growth and you fix many things.

We have, and every backbone is implementing it today, including Verio. Namely, give people who need to muti-home a /24, and let them announce that /24 from their own ASN. Simple, elegant, scalable (although not infinitely, but what is?), and working today. However, if all backbones took Verio's advice and filtered, this solution would no longer be workable. So, you may not fault them for taking a stance, but I do fault them for taking a stance and then acting in direct contradiction to that stance.

A more NANOG centric discussion may be to understand how many providers would have problems given larger route tables. We all don't have routers that can easily chew through a 100,000+ line BGP table.

Then you are in trouble, since the current table is already slightly over 100K prefixes. And most core routers at big networks (cisco GSRs, Juniper M###'s), can handle many more. (Lots of core routers already do - internal tables are frequently much larger than the global table.)

How much can we give to individual entities without endangering the common good?

That is not really the question being discussed. Right now we are deciding *which* entities we can give the freedom to announce what they please. Verio's "stance" does not prohibit networks or providers with large allocations to announce whatever they want. Also, many companies, schools, providers, etc., have very large IP allotments for which they would not qualify today (e.g. Apple, IBM, GE, MIT, etc. all have /8s.) The filtering policy does not affect these companies' & providers' announcements in the slightest. Only the new companies, the ones starting small and following the "rules" by not wasting space or asking for more than they really need, are hurt by this policy. In fact, one of the possible affects of this policy is the depletion of IP space at a much faster rate. For instance, companies with /24s on their NAT boxes and 1000s of employees would suddenly want - and qualify for - larger allocations to allow them to multi-home. Even if they only got a /20 for the NAT box, that would still increase IP address depletion rates alarmingly. Not to mention all the other companies & providers who would claim they need a /20 from the start, when they only need a /24 or less. Personally, I am far more afraid of running out of IP space than I am of router vendors not being able to handle 250K routes in a few years. (Juniper and cisco both claim they can do it today. I know Zebra can do it today on a single processor fast Pentium III box with a gig of RAM. Not exactly bleeding edge technology.) So, how much good does filtering do? And how much damage?

Joseph T. Klein +1 414 915 7489

-- TTFN, patrick

On Fri, 28 Sep 2001, Stephane Bortzmeyer wrote:

On Friday 28 September 2001, at 18 h 17, "Joseph T. Klein" <jtk@titania.net> wrote:

...

would have problems given larger route tables. We all don't have routers that can easily chew through a 100,000+ line BGP table.

I believe it is a legend. Unless you use Cisco 25xx to have a full BGP feed.

Any Taiwan-made PC can swallow much more. The limit is not clear but is certainly far away from us.

I'm pretty sure the limitations are dependant on how much memory one has in one's routers as opposed to the type of router used. (ie, a 75xx would run into problems if it has 128MB of RAM but not if it has 256MB given a 100k+ line BGP table) (But *please* correct me if I'm wrong) -- Bob <melange@yip.org> | We're all wrong.

At 21:32 +0200 28-09-2001, Stephane Bortzmeyer wrote:

On Friday 28 September 2001, at 18 h 17, "Joseph T. Klein" <jtk@titania.net> wrote:

...

would have problems given larger route tables. We all don't have routers that can easily chew through a 100,000+ line BGP table.

OK ... I amend my prior statement 250,000+ Yet, I don't belive every corner of every network has routers that can easily chew through 100,000 route tables.

I believe it is a legend. Unless you use Cisco 25xx to have a full BGP feed.

Yeah right. I suggest you look at real world loaded 7200s. They have problems with full routing tables.

Any Taiwan-made PC can swallow much more. The limit is not clear but is certainly far away from us.

I want to you to put a couple of channelized DS-3s, an ATM OC12c, and a POS OC48c to your backbone plus all the BGP peers you can sign up at AADS on a PC. The black and white simplicity expressed by people on this forum is unbelievable. -- Joseph T. Klein +1 414 915 7489 Senior Network Engineer jtk@titania.net Adelphia Business Solutions joseph.klein@adelphiacom.com "... the true value of the Internet is its connectedness ..." -- John W. Stewart III

At 16:13 -0400 28-09-2001, Patrick W. Gilmore wrote:

At 08:06 PM 9/28/2001 +0000, Joseph T. Klein wrote:

...

I want to you to put a couple of channelized DS-3s, an ATM OC12c, and a POS OC48c to your backbone plus all the BGP peers you can sign up at AADS on a PC.

Please show me a single router, from any vendor, which supports those interfaces yet cannot handle 100K+ routes. Even while under significant (but not 100%) load.

It depends on the stability of the routes. Conditions can exists that can arguably make either one of our statements true or false. I belive you will find older dark blue routers with bridges painted on them run out of gas trying to forward packet and deal with route changes no matter how much RAM you cram in them. Dampening is alternative way to filter.

...

The black and white simplicity expressed by people on this forum is unbelievable.

You mean like: "Yet, I don't belive every corner of every network has routers that can easily chew through 100,000 route tables." ??

Yes, like my simplistic statement on black and white simplicity.

...

Joseph T. Klein +1 414 915 7489

-- TTFN, patrick

-- Joseph T. Klein +1 414 915 7489 Senior Network Engineer jtk@titania.net Adelphia Business Solutions joseph.klein@adelphiacom.com "... the true value of the Internet is its connectedness ..." -- John W. Stewart III

Got a question, so a 7513MX2/8 fairly new model within Cisco still ONLY supports 256MB of Ram. So lets track the trends and try to predict when Cisco will force everyone into a new BGP master router? The issue as well remains that with 256MB RAM and RSP8 in a 7513 on a default free network having 200+ peering sessions and 100K+ routes consumes well over 128MB of RAM and the processor load spikes into the 80%-100% when major instabilites happen. Continue with uncontrolled growth to the Internet routing table and you will soon be replacing it with something bigger (but that would help the stock pricing rise aobe $12 share, huh). On Fri, 28 Sep 2001, Vincent J. Bono wrote:

...

...

Any Taiwan-made PC can swallow much more. The limit is not clear but is certainly far away from us.

...

I want to you to put a couple of channelized DS-3s, an ATM OC12c, and a POS OC48c to your backbone plus all the BGP peers you can sign up at AADS on a PC.

Yes but you can't put all that on the "loaded" 7200s you mentioned either. I think the point he was trying to make was not that we should use PCs as routers, but that routers we *do* use are at least as powerful as Taiwan PCs (for this application).

When Sprint was filtering there was a demonstrable need based on the 64meg limit that mainstream routers had for memory at the time. I do not see that there is any such physical limitation today and I guarentee that the router vendors (all two of them) have learned the lesson of not including enough address lines on the equipment to allow for easy memory upgrades.

-vb

There is also a point that many folks may be missing. The 7200 and 7500 routers, while ubiquitious, are not new models. These are 5 year-old devices, which have been progressively retrofitted with new CPUs, and are based on even older technology. There have been assertions made that telco equipment is expected to last for 20 years - this is true. However, we are at a much later stage in the maturity of voice phone switches. It will take a few more (albeit costly) cycles of equipment replacement for routers to last anywhere near that long. However, for computing equipment, the 7xxx class of routers has aged quite well. How many of us are running with 5 year-old PCs on our desks? Now, contrast this to how many of us have 7200s or 7500s in our networks... - Dan

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Stephane Bortzmeyer Sent: Sunday, September 30, 2001 8:19 AM To: Michael Whisenant Cc: nanog@merit.edu Subject: Re: The Gorgon's Knot. Was: Re: Verio Peering Question

On Friday 28 September 2001, at 15 h 33, Michael Whisenant <mwhisen@foreigner.whisenant.net> wrote:

...

Got a question, so a 7513MX2/8 fairly new model within Cisco still ONLY supports 256MB of Ram. So lets track the trends and try to predict when Cisco will force everyone into a new BGP master router? ... Continue with uncontrolled growth to the Internet routing table and you will soon be replacing it with something bigger

This is a problem only for people using Ciscos. (Maximum 256 Mb of RAM on a modern machine, not a washing machine, but an INTERNET ROUTER, I must be dreaming...)

Like with Microsoft's broken software I seriously object harassing everybody just because Cisco is not able to do better.

On Mon, Oct 01, 2001 at 12:29:43PM -0700, Vadim Antonov reportedly typed:

The original 7000s (with SP if anyone remebers that beast) were slower even that AGS/+ ...

yes, and I remember begging for SSE upgrades. I also remember paging MFS Datanet techs to reboot Net99's routers at least once, maybe twice a week to reboot our router because of route-flap meltdowns at the MAE's.

7000s are probably the worst-designed piece of hardware from Cisco. The only benefit of replacing AGS/+ es at the time 7000 was introduced was that some smarthead designed AGS/+ w/o enough address leads, so they topped at 16Mb of RAM.

And when the 7500 was first introduced in '95, the RSP1 and no VIPs it actually performed worse than the 7000. The 7500's that may be deployed today are nothing like the ones we had 5-6 years ago. Not only are we in our 4th generation of RSP, but we're in our 3rd (plus intermediate upgrades) of VIP. Even your bus might be different now (Czbus). We were facing a real, live, brick wall back then. We weren't fighting for long-term scalability, it was short-term survivability. That's a pretty serious contrast with todays environment.

PS Longevity-speaking - it is not technology which really matters, it is architecture. You can buy a box now which you can still be using 10 years later, given the exponential traffic growth. Won't cost you arm and leg, too.

Indeed, we may still be deploying 7500's at the edge in 5 years, but I doubt anyone will really want to...and I suspect Cisco will EOL long before then. And, there may be a possibility that the high-end Cisco and Juniper gear that many of us use today may be useful at the edge in 10 years, but I kinda doubt that. That leaves multi-chassis solutions, which aren't *quite* ready to deploy, but are getting closer every month. That architecture certainly has long-term potential. Is that what you're alluding do, or something different? In all of these cases, the technology *absolutely* does matter. Technology drives architecture. Architecture may resolve technology issues, or technology may make new architectures available that weren't possible before. Dave

On Mon, 1 Oct 2001, Daniel Golding wrote:

...

There is also a point that many folks may be missing. The 7200 and 7500 routers, while ubiquitious, are not new models. These are 5 year-old devices, which have been progressively retrofitted with new CPUs, and are based on even older technology.

There have been assertions made that telco equipment is expected to last for 20 years - this is true. However, we are at a much later stage in the maturity of voice phone switches. It will take a few more (albeit costly) cycles of equipment replacement for routers to last anywhere near that long. However, for computing equipment, the 7xxx class of routers has aged quite well. How many of us are running with 5 year-old PCs on our desks? Now, contrast this to how many of us have 7200s or 7500s in our networks...

- Dan

-- Dave Siegel HOME 520-877-2593 dave at siegelie dot com WORK 520-877-2628 dsiegel at gblx dot net Director, IP Engineering, Global Crossing

No, please no :( Not more Gibson !! If the government of the United States needs to turn to Steve Gibson for ideas on how to fight cyber terrorism we are in deep trouble. If only 5 days are to be spent on drafting such a proposal, I wonder why they would bother. I read the post below. The proposals that Steve has drafted are laughable ! The scale of work that would need to be done in order to protect NA from cyber terrorism is unimaginable. Telling Internet users not to open email attachments if far from a solution. ----- Original Message ----- From: "Mike Batchelor" <mikebat@tmcs.net> To: <nanog@merit.edu> Sent: Monday, October 01, 2001 5:53 PM Subject: Your customer's favorite guru (grc and OT)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Is this guy for real?

https://grc.com/x/news.exe?cmd=article&group=grc.news&item=211&utag=

-----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBO7jl0UksS4VV8BvHEQJeMgCguKCWXsDavmzz1dMaouJf0Qu6w5oAoJ6V y6XHkN2e83coeat5pmOkk3Wy =Sut8 -----END PGP SIGNATURE-----

On Mon, 01 Oct 2001 18:44:05 EDT, Wojtek Zlobicki <wojtekz@idirect.com> said:

I read the post below. The proposals that Steve has drafted are laughable ! The scale of work that would need to be done in order to protect NA from cyber terrorism is unimaginable. Telling Internet users not to open email attachments if far from a solution.

On the flip side, if you can't keep the users from doing stupid things, how will you ever secure it? Yes, his proposals are laughable - but do you want to even TRY to secure an infrastructure where Gibson's stuff is NOT done? On the other flip side, the SANS 'Top 20' list was also released today (http://www.sans.org/top20.htm). I'd like to state that the inclusion of Sendmail rather than telnetd as a "top Unix problem" was Not My Fault. ObNANOG: I *will* take the blame for the reference to RFC1918 addresses in tne top-20 document. (No, I do NOT want to re-start the flame war - this is just a heads-up for those who get to do troubleshooting). Valdis Kletnieks Operating Systems Analyst Virginia Tech

On Mon, 1 Oct 2001, Sean Donelan wrote:

On Mon, 1 Oct 2001 Valdis.Kletnieks@vt.edu wrote:

...

On the flip side, if you can't keep the users from doing stupid things, how will you ever secure it? Yes, his proposals are laughable - but do you want to even TRY to secure an infrastructure where Gibson's stuff is NOT done?

A dumb suggestion, but why doesn't Microsoft hire AOL to include all its recommended patches for Windows on the CD's AOL sends to everyone on the planet?

Because it's already full?

On Mon, 01 Oct 2001 18:18:04 -1000, Michael Painter <tvhawaii@shaka.com> said:

Valdis

Is this what you're referring to?

5. Any packet coming into your network or leaving your network must not have a source or destination address of a private address or an address listed in RFC1918 reserved space. These include 10.x.x.x/8, 172.16.x.x/12 or 192.168.x.x/16 and the loopback address 127.0.0.0/8.

Yep. I also did a lot of other changes that are in the document, and a lot of suggested changes that didn't go in, but that one's the part that most affects the NANOG readership. /Valdis

On Friday 28 September 2001, at 20 h 6, "Joseph T. Klein" <jtk@titania.net> wrote:

Yeah right. I suggest you look at real world loaded 7200s. They have problems with full routing tables.

I don't know, I don't use Ciscos and I don't regret it.

...

Any Taiwan-made PC can swallow much more. The limit is not clear but is certainly far away from us.

I want to you to put a couple of channelized DS-3s, an ATM OC12c, and a POS OC48c to your backbone plus all the BGP peers you can sign up at AADS on a PC.

Come on, I did not say that a PC can handle everything, just that it can handle easily 100k routes. I don't know the limit but neither do you (did you try the funny experiment you suggest or are you just guessing?) The only thing I'm sure, because I run it daily, is that 100k routes is not a lot for today's machines.

The black and white simplicity expressed by people on this forum is unbelievable.

The ability of some people to continue the discussion about the "routing table explosion" legend as if we were still in a world of 64 mega-bytes routers (with a Motorola 68020) is unbelievable.

On Friday 28 September 2001, at 20 h 6, "Joseph T. Klein" <jtk@titania.net> wrote:

...

Yeah right. I suggest you look at real world loaded 7200s. They have problems with full routing tables.

I don't know, I don't use Ciscos and I don't regret it.

...

...

Any Taiwan-made PC can swallow much more. The limit is not clear but is certainly far away from us.

I want to you to put a couple of channelized DS-3s, an ATM OC12c, and a POS OC48c to your backbone plus all the BGP peers you can sign up at AADS on a PC.

Come on, I did not say that a PC can handle everything, just that it can handle easily 100k routes.

I don't know the limit but neither do you (did you try the funny experiment you suggest or are you just guessing?) The only thing I'm sure, because I run it daily, is that 100k routes is not a lot for today's machines.

...

The black and white simplicity expressed by people on this forum is unbelievable.

The ability of some people to continue the discussion about the "routing

There are two separate problems I think with core routers. A number of router platforms, like Juniper, have lots of core memory on their main CPU [like 768MB I think]. This is fine to hold all the views of all your peers, etc. Even a PC can handle this task and calculate convergence. 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. This causes operators of this sort of a equipment difficulties in longer convergence times and less than ideal routing performance. While its great to say we can all upgrade our core routing equipment every 9-12 months, which is often the case for business reasons, not all of us want the OBLIGATION to, and filtering is one way to ensure increased longevity of your equipment. We can always bring up the idea of using PCs for peering, and real routers for forwarding/packet filtering, but you are essentially asking the operators of backbones to absorb additional operations expense [in terms of maintaining multiple platforms] for reason that benefits _their_ business model. 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. You can put many interfaces in a PC, or several PCs and not need a dedicated 16 slot chassis, but when you are aggregating many interfaces and they are moving well over 800mb/s, there aren't too many options. This completely ignores the fact that a core router doesn't want to be touched under any circumstance, and engineers come up with LOTS and LOTS of good reasons why you need to wait until the router is ready to fall over before scheduling a maintenance window on it. Just my opinion, YMMV. Deepak Jain AiNET -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Joseph T. Klein Sent: Sunday, September 30, 2001 11:34 AM To: Stephane Bortzmeyer Cc: nanog@merit.edu Subject: Re: The Gorgon's Knot. Was: Re: Verio Peering Question At 13:54 +0200 30-09-2001, Stephane Bortzmeyer wrote: table

explosion" legend as if we were still in a world of 64 mega-bytes routers (with a Motorola 68020) is unbelievable.

Muck through the archives ... you will find me on the other side of the argument. A PC with the big interfaces is called a Juniper. ;-) The problem is at the core, not at the edge. You can put a PC in many places but not in a high bandwidth, peer rich location. -- Joseph T. Klein +1 414 915 7489 Senior Network Engineer jtk@titania.net Adelphia Business Solutions joseph.klein@adelphiacom.com "... the true value of the Internet is its connectedness ..." -- John W. Stewart III

Lucent's Optistar line is available in OC12 and OC48 versions. Deepak Jain AiNET -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Mr. James W. Laferriere Sent: Sunday, September 30, 2001 1:02 PM To: Stephane Bortzmeyer Cc: Joseph T. Klein; nanog@merit.edu Subject: Re: The Gorgon's Knot. Was: Re: Verio Peering Question Hello All, Darn I hate this , But I have to chime in here . On Sun, 30 Sep 2001, Stephane Bortzmeyer wrote:

On Friday 28 September 2001, at 20 h 6, "Joseph T. Klein" <jtk@titania.net> wrote:

...

Yeah right. I suggest you look at real world loaded 7200s. They have problems with full routing tables. I don't know, I don't use Ciscos and I don't regret it.

...

Any Taiwan-made PC can swallow much more. The limit is not clear but is certainly far away from us.

...

I want to you to put a couple of channelized DS-3s, an ATM OC12c, and a POS OC48c to your backbone plus all the BGP peers you can sign up at AADS on a PC. Come on, I did not say that a PC can handle everything, just that it can handle easily 100k routes. It is now quite possible to have a 64bit pci system with an oc-48 card in it . Check around folks they are there . Not cheap at all but available . The chennelised cards may be a little harder to find but I'd even bet they're out there already . I do know the oc-12c cards are . Try Marconi or InterPhase or ...

I don't know the limit but neither do you (did you try the funny experiment you suggest or are you just guessing?) The only thing I'm sure, because I run it daily, is that 100k routes is not a lot for today's machines. Joe May darned well have tried ;-) . But I and maybe a few others may even know that the Larger optical cards are available . I sure have not seen any mention on this list about them . Or any other lists for that matter . Twyl , JimL

...

The black and white simplicity expressed by people on this forum is unbelievable. The ability of some people to continue the discussion about the "routing table explosion" legend as if we were still in a world of 64 mega-bytes routers (with a Motorola 68020) is unbelievable.

+------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+

At 08:40 PM 9/28/2001 +0000, Joseph T. Klein wrote:

I used the wrong mythological/legendary reference.

It was the Gordian knot that Alexander cut.

So who is the Alexander of routing conundrums?

Well, Sean Donelan reports most cuts. Does that count? :)

Joseph T. Klein +1 414 915 7489

-- TTFN, patrick

On Fri, Sep 28, 2001 at 02:59:34PM -0700, Rachel Warren wrote:

...

So who is the Alexander of routing conundrums?

I can't think of anyone who could be comparable to Alexander. I can imagine one could make a favorable comparison to Alexander's pedagogue, Aristotle, to someone who has written/taken part in quite a few RFC's.

Upon the mention of Mr. Donelan, I had an image of him sitting on a backhoe and cutting into a giant copy of the interconnection-mesh image from the CAIDA posters... but I'm feeling much better now. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/

I don't think anyone has ever claimed (Randy included) that filtering out long prefixes never hurts performance /to those long prefixes/. Just that the usage of those long prefixes is small, the effect is often small, and the NET effect (i.e. on performance to all prefixes) is often improved, AND the 'public good' effect, in terms of encouraging CIDR and discouraging disaggregation has benefits for the global routing table, for everybody, in terms of reduction of cost (nice statistical demonstration at last IETF Ptomaine session - please refer to 'belling the cat' problem).

Are you going to present statistical data to the contrary?

<http://psg.com/~rand/010809.ptomaine.pdf> randy

try a little harder - http://psg.com/~randy/010809.ptomaine.pdf Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch@darkwing.uoregon.edu (541) 346-1774 Cell: (541) 912-7998 5419127998@mobile.att.net On Thu, 27 Sep 2001, Patrick W. Gilmore wrote:

At 04:31 PM 9/27/2001 -0700, Randy Bush wrote:

...

...

I don't think anyone has ever claimed (Randy included) that filtering out long prefixes never hurts performance /to those long prefixes/. Just that the usage of those long prefixes is small, the effect is often small, and the NET effect (i.e. on performance to all prefixes) is often improved, AND the 'public good' effect, in terms of encouraging CIDR and discouraging disaggregation has benefits for the global routing table, for everybody, in terms of reduction of cost (nice statistical demonstration at last IETF Ptomaine session - please refer to 'belling the cat' problem).

Are you going to present statistical data to the contrary?

<http://psg.com/~rand/010809.ptomaine.pdf>

Not Found The requested URL /~rand/010809.ptomaine.pdf was not found on this server.

Sorry. :(

...

randy

-- TTFN, patrick

...

<http://psg.com/~rand/010809.ptomaine.pdf> ^y

http://psg.com/~randy/010809.ptomaine.pdf sorry

This shows the inherent hypocrisy of Verio's position. They claim that they won't accept these routes from peers, as a way of contributing to the public good, and limiting routing table size. However, that goes right out the window, when a little cash is waved around. The real reason for Verio's position could easily be that it is an effort to force those who are announcing prefixes that they will not listen to from peers, to buy transit directly from Verio. I think Sprint should be applauded from dropping their antiquated routing policy. Verio should definitely be passed over when folks are making transit-buying decisions, as they implement a filter policy that is basically anti-social. Those who extol the virtues of aggressive filtering, also tend to be the same folks who denounce multihoming, other than by a select few, in the name of lofty concepts such as controlling routing table size. However, the empirical evidence of the last few years, when /24s have become essentially globally routable (excluding neo-luddite carriers such as Verio), prove the fallacy of this viewpoint. - Daniel Golding

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Craig Pierantozzi Sent: Thursday, September 27, 2001 9:24 PM To: nanog@merit.edu Subject: Re: Verio Peering Question

* Thus spake Patrick W. Gilmore (patrick@ianai.net):

[snip]

...

Oh, one other point - Verio accepts smaller announcements from their customers - and propagates them. I guess Verio agrees that

other people

...

can run networks with all the extra announcements, even if Verio themselves cannot.

The rationale stated in past threads is that Verio's customers pay for this service. Non-customers are not paying Verio for anything therefore they do not choose to accept the more specific announcements from other providers.

Other providers have not taken this stance as shown by the list of those that accept more specifics from peers.

cheers -cp

At 10:20 PM 9/28/2001 -0700, Randy Bush wrote:

my time flies. it's so comforting to have this discussion again so we don't have to think and can just reiterate the same old flamage. or maybe the net is now old enough that a significant proportion of our population has altzheimers. i will 'fess up to having 'senior moments' myself.

First, while the flames may be the same, the times they are a changing. What was good "back then" may or may not be good now. That said, I have tried (and succeeded, I think) to keep from commenting on the Sprint filters, other than to relate historical fact.

the only new thing this time is that you now have a financial interest in routing table pollution. or am i mistaken that sockeye devices will be announcing small prefixes in an attempt to steer inbound traffic?

You are mistaken. Sockeye does not inject prefixes into the global table. Tell me, did you have any operational content to post, or just erroneous flames? "Resist the cycle of useless posts, boys and girls." And do it 'cause someone with clue just told you to. :)

randy

-- TTFN, patrick (not an employee of Sockeye)

Ah, I'm afraid you are having a "senior moment" :). Sockeye devices do not steer inbound traffic by announcing small prefixes (or any prefixes). Competitors might (or might not), but we don't. Any routes advertised by our devices will always have the no-advertise or no-export well-known communities, as an additional safety measure to prevent route table pollution of any type.

sounds great! thank you. randy