- NANOG - lists.nanog.org

Re: Verio Decides what parts of the internet to drop
by Sean Donelan 04 Dec '99

04 Dec '99

On Sat, 04 December 1999, smd(a)clock.org wrote: > Peers and customers are currently indistinguishable. > > A peer is simply a customer who receives limited connectivity, > usually constrained by BGP announcement filtering in both directions, > for a heavy discount, sometimes as much as 100% off normal pricing. > > A supplier, on the other hand, is someone who sends you a bill, > even if that bill is hugely discounted, with the expectation that if > it is not paid, the connectivity offered as a service will be terminated. I don't understand your "other hand." Using your logic, not only are peers and customers indistinguishable, but peers and suppliers are also indistinguishable. A customer, on the other hand, is someone who receives your bill, even if that bill is hugely discounted, with the expectation that if it is not paid, the connectivity received as a service will be terminated. A peer is simply a supplier who gives a limited selection of connectivity, usually constrained by BGP announcement filtering, for a heavy discount, sometimes as much as 100% off normal pricing. The problem with equating "peer" with either customer or supplier is you can never figure out who is the customer and who is the supplier. If I send you a bill every month for $0.00, does that make me the supplier and you the customer? To make things even more confusing, there are usually additional requirements peers must comply with, that neither customers nor suppliers do. Why do you think the lawyers go cross-eyed everytime they try to understand a peering agreement.

1 0

RE: Verio Decides what parts of the internet to drop
by smd＠clock.org 04 Dec '99

04 Dec '99

| If filter policies like Sprint's and Verio's really are common among the | big backbone providers, that would seem to make it relatively pointless to | attempt to multi-home with provider supplied IP space. We have a customer | interested in multihoming for reliability, but they use so little IP | space, even assigning them a /24 would be a stretch. Please see RFC 2260. http://www.faqs.org/rfcs/rfc2260.html Sean.

2 1

Re: Verio Decides what parts of the internet to drop
by Sean Donelan 04 Dec '99

04 Dec '99

On Fri, 03 December 1999, Tony Li wrote: > I was not and am not suggesting that anyone stop all filtering. I am > suggesting that a sane prefix settlement scheme would allow us to dispense > with the filtering policies that are currently in place and would allow the > backbone to globally distribute any prefix, regardless of prefix length, if > only the originator has paid enough money and informed people first. You > want to inject a /32? Go right ahead. Send your check to your provider > and it can be made to happen. Such a payment scheme has always existed. The provider with the most agressive filtering policy has always announced many prefixes which they wouldn't accept if the networks were customers of a different provider. Just make your checks out to all the providers you want to reach, and they'll each be happy to install a seperate circuit for your network. It worked for tymnet, telenet and compuserve. In today's Internet a difficult problem is figuring out if they are announcing a /32 accidently, for a dumb reason or for a good reason. Because my upstream provider is too dumb to aggregate isn't a good reason.

1 0

None
by Charles E. Yow, Esq. 04 Dec '99

04 Dec '99

On December 2, 1999 MCI/Worldcom had another outage in Southern Mississippi lasting 9 hours, shutting down local ISPs, however the MCI net in the same are was functioning without difficulty, how can I find if they re-routed their users. Charles Yow

1 0

Re: Verio Decides what parts of the internet to drop
by smd＠clock.org 04 Dec '99

04 Dec '99

| Great idea, but charges should apply to _peers_, not customers. Peers and customers are currently indistinguishable. A peer is simply a customer who receives limited connectivity, usually constrained by BGP announcement filtering in both directions, for a heavy discount, sometimes as much as 100% off normal pricing. A supplier, on the other hand, is someone who sends you a bill, even if that bill is hugely discounted, with the expectation that if it is not paid, the connectivity offered as a service will be terminated. This taxonomy is convenient in that it leaves one with a small grey area wherein neither party sends the other a bill, and neither party has the right to demand that service continues for a particular amount of time. | Charging customers for announces prefixes merely creates an incentive | for backbone operators to announce more routes and, correspondingly, | collect more money. If network X is sending network Y too-long prefixes, or too many prefixes, network X may choose to filter them, or require that they be aggregated. A customer paying a larger amount of money is likelier to have this demand met than a customer with a very steep discount. A supplier, on the other hand, may choose to increase the bill when faced with a customer who sends inappropriate prefixes. In the grey area, who knows? So far the only answers there have been inbound filtering and proxy aggregation. Sean.

1 0

Re: Verio Decides what parts of the internet to drop
by smd＠clock.org 04 Dec '99

04 Dec '99

| Now I don't claim to be a policy wonk and I don't have the | slightest idea of how to make this equitable and fair for all, but I do | know that this would result in an outcome that would give us routing tables | far smaller than our current 67k entries. It doesn't need to be equitable and fair to all; the fact is that I consider my routing table slots to be a scarce resource, and I will conserve that resource. Filtering is one approach; a step towards your approach is relaxing filters for people willing to pay me money to do so. I am sure that if someone with a too-long prefix went to a filtering provider and offered a (probably small) fee, a permanent hole in the inbound filters would be made. We arrive at your approach when we have the ability for someone with a too-long prefix to find every provider who is filtering out the prefix, and negotiate some sort of deal which ends up with a modification to their local filter list. This is a bit unwieldy, since in principle, every routing domain in the Internet might put up filters, and while it is true that perhaps not all of them are someone a person with a too-long prefix would want to talk to at any price greater than $0, a large set will be worth more. Several thousand negotiations (or even several hundred, or even several dozen, and possibly just several) likely will dissuade most people from trying to use a too-long prefix the first place. People with hardcore reasons for using a too-long prefix will probably be willing to pay a fee to an agent able to broker cheapest-possible access to the routing slots in the networks that are smart enough to sell them. As with any market negotiations, some users of a too-long prefix will get a better deal than others. Likewise, some networks can demand higher prices than others. Right now, there are only two known prices for access to routing slots by holders of any prefix of any length: $0 and $infinity. Unfortunately, people on NANOG are much more likely to jump up and down and scream and play politics and whine that THEIR long prefixes are so vitally important that nobody should charge them money for permitting them to occupy routing slots everywhere (because it is against the spirit of the Internet or something like that), than to negotiate an actual price less than $infinity simply by contacting the filtering provider(s) and making an initial offer (or asking them to do so). Your proposal likely will never fly while people in the industry remain hostilely unpragmatic and opposed to free market forces. However, should that change, there are fiddly little details which would have to be worked out; the ugliest of which would be a case where a provider which filters is willing to relax the filter-list in exchange for a small fee, but _it's_ provider is not (or demands a fee the originator is not willing to pay). Another take on this is to consider a global transit network and a national or regional transit network, each of which charges a small price for relaxing a filter against too-long prefixes. If the contract with the global transit network expires, and that GTN is the only direction the national network sees the too-long prefix, what then? A practical technical solution to this would allow "intermediate" backbones to enter into the game of selling routing slots in their networks, no matter what the "top tier" backbones do. | The correlation with route flap should be re-examined. I suspect that this | is no longer a driving force and is more than adequately compensated for by | having flap damping parameters that scale geometrically with the prefix | length. I agree that it should be re-examined, and I have the same suspicion. I believe the problem now is dealing with huge numbers of prefixes (thanks to the trend towards ever smaller networks multihoming) and their dynamism over a longer term than flap-dampening code considers. Sean.

1 0

Filter Policies (was: Re: Verio Decides what parts of the internet to drop)
by Jan Ahrent Czmok 04 Dec '99

04 Dec '99

Hello! IMHO, i also propose to have a clear discussion about some issues which came into my mind when reading all this mails. The next NANOG might be really a good place for this issue. There are some unanswered things: - optimize the Routing Table (e.g. how to come to an agreement with even the largest isps but also including smaller ones) - recent discussed Authorization of Routes and validation - how we all together can get rid of the swamp space (e.g. it MUST the possible somehow) - hints and tips and coordination of filter policies. But these are just my .5 cents Jan

1 0

Geektools SuperWhois update (re: Internic)
by Rodney Joffe 04 Dec '99

04 Dec '99

As you by now know, as of two hours ago (Dec 1, EST) Network Solutions changed their whois to "the new form". NSI being their normal secretive selves, it appears that their new whois servers are not giving out the "correct" information. They show the authoritative whois server for their registrar as rs.internic.net, which, of course, shows the same info as crsnic. $ whois geektools.com(a)rs.internic.net [rs.internic.net] Whois Server Version 1.1 Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: GEEKTOOLS.COM Registrar: NETWORK SOLUTIONS, INC. Whois Server: rs.internic.net Referral URL: www.networksolutions.com Name Server: NS1.ULTRADNS.NET Name Server: NS2.ULTRADNS.NET >>> Last update of whois database: Tue, 30 Nov 99 00:40:30 EST <<< The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and Registrars. It appears that whois.networksolutions.com does give the detailed whois data. We can't tell if this is an oversight, or on purpose. None-the-less... We've updated geektools superwhois (both the GUI at www.geektools.com and the command line proxy at whois.geektools.com) to use whois.networksolutions.com when appropriate. This 'breaks' the normal operation of SuperWhois which correctly looks at crsnic first, then the referred server. In this case, crsnic also says rs.internic.net. We'll watch the bouncing ball, and when crsnic starts giving the correct answer (whether whois.networksolutions.com or another) we'll undo the hack. The source tarballs are updated also, showing version 2.2.2. If NSI pulls something else strange, we'll release 2.2.2a pronto. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"

2 2

Re: Verio Decides what parts of the internet to drop
by Vadim Antonov 03 Dec '99

03 Dec '99

Tony Li wrote: > Wouldn't it be nice if backbones got around to simply charging for annoucements > and quit this arbitrary filtering? Great idea, but charges should apply to _peers_, not customers. Charging customers for announces prefixes merely creates an incentive for backbone operators to announce more routes and, correspondingly, collect more money. --vadim

2 1

The Cidr Report
by Tony Bates 03 Dec '99

03 Dec '99

This is an auto-generated mail on Fri Dec 3 12:00:01 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 03Dec99 0) General Status Table History ------------- Date Prefixes 261199 67449 271199 67441 281199 67471 291199 67421 301199 67403 011299 67418 021299 67533 031299 67454 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 64.4.64.0/19 from AS7398 *** Bogus 64.6.32.0/20 from AS13740 *** Bogus 64.6.64.0/20 from AS10726 *** Bogus 219.91.160.0/22 from AS7742 *** Bogus 219.91.164.0/23 from AS7742 AS Summary ---------- Number of ASes in routing system: 6165 Number of ASes announcing only one prefix: 3283 (1798 cidr, 1485 classful) Largest number of cidr routes: 637 announced by AS701 Largest number of classful routes: 974 announced by AS701 1) Gains by aggregating at the origin AS level --- 03Dec99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 383 141 242 63.2% BCnet Backbone AS7046 386 250 136 35.2% UUNET-CUSTOMER AS2609 126 11 115 91.3% EUnet-TN AS1221 633 519 114 18.0% TELSTRA-AS AS9269 130 28 102 78.5% Hong Kong CTI AS9706 112 11 101 90.2% Pusan Metropolitan City Office of AS7657 267 170 97 36.3% The Internet Group Limited AS1653 129 38 91 70.5% SUNET Swedish University Network AS7545 147 59 88 59.9% TPG Internet Pty Ltd AS174 565 479 86 15.2% Performance Systems International AS4293 227 142 85 37.4% Internal ASN for C&W AS7496 123 40 83 67.5% Power Up AS577 262 182 80 30.5% Bell Canada Backbone AS3749 136 62 74 54.4% TECNET AS4200 179 109 70 39.1% AGIS (Apex Global Information Ser AS3602 314 246 68 21.7% Sprint Canada Inc. AS816 255 196 59 23.1% UUNET Canada (ASN-UUNETCA-AS4) AS705 137 78 59 43.1% ALTERNET-AS AS4740 349 291 58 16.6% Ozemail Pty Ltd (ASN-OZEMAIL) AS209 334 279 55 16.5% Qwest Communications AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS701 974 931 43 4.4% Alternet AS9304 58 18 40 69.0% Hutchcity AS1 519 479 40 7.7% GTE Internetworking AS6528 45 7 38 84.4% WORLD-LYNX AS8013 135 99 36 26.7% PSINET-CA AS549 205 169 36 17.6% ONet Backbone AS4755 105 69 36 34.3% Videsh Sanchar Nigam Ltd. India AS7568 50 15 35 70.0% C.S. Communications Co., Ltd. AS3737 99 66 33 33.3% PenTeleData Inc. (ASN-PTD) For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0