- NANOG - lists.nanog.org

Re: Peering Disputes
by Sean Donelan 14 Jan '01

14 Jan '01

On Sat, 13 January 2001, marcellus(a)bbo.com wrote: > I liked your run down on Peering disputes. However, I know there are alot of > us out there who have been involved in many other rather nasty ones. I understand there have been a less public disputes between providers. My list covered the "public" ones. I know my list is a bit one-sided. Whether folks believe it or not, even I respect NDAs. One weird thing about NDA is they sometimes keep me from talking about the good things providers do, as well as the bad things. There are providers I think handle peering very well, whether or not they peered with me. I expect the same is true of other people involved in peering. So we're always going to hear a one-sided story. I don't know if enough time has passed, but I hope at some point in time a researcher can get folks from the first peering battle on the same panel and document what happened directly from the source. Imagine Allan Weis (ANS), Rick Adams (UUNET), Stephen Wolff (NSF), Marty Schoffstall (PSI) and John Curran (BBN) on a panel discussing what they thought really happened. Its not really a NANOG topic, but maybe Harvard, CNI or one of the other think tank institutions.

1 0

Re: UUNET peering policy
by Sean Donelan 14 Jan '01

14 Jan '01

On Thu, 11 January 2001, Rodney Joffe wrote: > I also don't believe that it was a coincidence that Genuity/GTE was the > first to make a public statement of it's peering policy. Sometimes I think "Internet Time" also applies to its long term memory. One of the reasons why I asked for copies of old peering policies is because essentially every major provider has publically announced their policy at one time or another in the last decade. Saying "First" about anything should mean more than the last 18 months. InternetMCI had their peering policy on their web site for several years (1995-1996) prior to its acquisition by Worldcom. I believe InternetMCI removed their peering policy from its public web site about the time Farouq took over peering at MCI. The first peering battle was ANS. The agreement was brokered by BBN arranging for ANS to connect to the CIX router. At that point, the definition of "being on the Internet" changed from being connected to the NSFNET to being on the commercial Internet, and the set of providers supplying commercial Internet service. The second peering battle was one of packet loss. Sprint tried to make things as painful as possible by never upgrading its connection to the CIX router above a T1. So even though other providers were exchanging traffic at 34Mbps to 45Mbps, Sprint kept their quality of service limited to 1.5Mbps at the CIX. This one was never directly resolved. But by this time most providers were exchanging a majority of their traffic via MAE-East. Around this time BBN transitioned from being a customer of InternetMCI to being a peer of InternetMCI using its connections via several old NSF regional networks (BARRNET, SURANET and NEARNET). BBN and MCI may have had the first "private" circuit peering. Because InternetMCI had sold connectivity as a loss-leader to the old NSF regionals, some folks throught MCI was happy to get out of the customer contract. The third peering battle involved disconnectivity. BBN was one of the first providers to terminate its connection to the CIX router, which had previously acted as the peering point of last resort, and began the second round of peering disputes. When all the major providers connected to the CIX, it was difficult for any provider not to peer because the CIX router always offered a way to exchange traffic. In less than three months, BBN, MCI and Sprint actions eliminated CIX as the router of last resort. It should be noted, UUNET has maintained its connection to the CIX router. Any provider interested in exchanging traffic with UUNET has always had the option of sending traffic via the CIX. This option does not exist for Genuity or Sprint. The fourth peering battle involved AGIS announcing its new peering policy at the least NANOG meeting held at the University of Michigan. It generated a lot of noise, but eventually AGIS's peering policy became irrelevant. Towards the end, AGIS was actively trying to get peering with new providers. The fifth peering battle involved UUNET. UUNET notified some number, I've heard between 10 and 20, providers UUNET would terminate their peering. At this time in the Internet's history only a few providers had written peering agreements. There were very few NDA's involved with peering before this time. It probably wasn't a breach of NDA, but someone leaked the story to the press. UUNET eventually was able to shutdown the story, but that lead to the next problem. Everything is a secret, so people imagine things were in peering agreements. The sixth peering battle involved once again BBN/GTE and the MCI/Worldcom merger. GTE worked very diligently to bring the issue of peering to the attention of regulators in the US and Europe. Eventually the EU Commission issued administrative inquires of all the major providers about the nature of the agreements, the amount of traffic, the types of connections and so forth. In the end, the nature of peering agreements wasn't clarified, but Worldcom had to spin off its InternetMCI division to Cable & Wireless. The seventh peering battle involved again BBN/Genuity/GTE and Exodus. This time it was the battle over imbalanced traffic flows. BBN and Exodus had a dispute, but it was settled and as they say on TV the terms were not announced. The imbalance issue has come up a few more times with other providers such as PSI, Abovenet and others. So, even though some folks like to point to UUNET as the big bully on the block, if you look at history; BBN has more often than not been the power behind the throne in these peering battles.

2 1

Peering Disputes
by marcellus＠bbo.com 14 Jan '01

14 Jan '01

Sean, I liked your run down on Peering disputes. However, I know there are alot of us out there who have been involved in many other rather nasty ones. In my case, both resulted in my company's total disregard of my counsel. I'd be very interested in hearing other's feelings on this. -------------------------------------------------------- Marcellus Smith Manager - Peering <marcellus(a)bbo.com> 571.226.1223 Office 703-395-4275 Cell -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Saturday, January 13, 2001 10:57 PM To: rjoffe(a)centergate.com Cc: nanog(a)merit.edu Subject: Re: UUNET peering policy On Thu, 11 January 2001, Rodney Joffe wrote: > I also don't believe that it was a coincidence that Genuity/GTE was the > first to make a public statement of it's peering policy. Sometimes I think "Internet Time" also applies to its long term memory. One of the reasons why I asked for copies of old peering policies is because essentially every major provider has publically announced their policy at one time or another in the last decade. Saying "First" about anything should mean more than the last 18 months. InternetMCI had their peering policy on their web site for several years (1995-1996) prior to its acquisition by Worldcom. I believe InternetMCI removed their peering policy from its public web site about the time Farouq took over peering at MCI. The first peering battle was ANS. The agreement was brokered by BBN arranging for ANS to connect to the CIX router. At that point, the definition of "being on the Internet" changed from being connected to the NSFNET to being on the commercial Internet, and the set of providers supplying commercial Internet service. The second peering battle was one of packet loss. Sprint tried to make things as painful as possible by never upgrading its connection to the CIX router above a T1. So even though other providers were exchanging traffic at 34Mbps to 45Mbps, Sprint kept their quality of service limited to 1.5Mbps at the CIX. This one was never directly resolved. But by this time most providers were exchanging a majority of their traffic via MAE-East. Around this time BBN transitioned from being a customer of InternetMCI to being a peer of InternetMCI using its connections via several old NSF regional networks (BARRNET, SURANET and NEARNET). BBN and MCI may have had the first "private" circuit peering. Because InternetMCI had sold connectivity as a loss-leader to the old NSF regionals, some folks throught MCI was happy to get out of the customer contract. The third peering battle involved disconnectivity. BBN was one of the first providers to terminate its connection to the CIX router, which had previously acted as the peering point of last resort, and began the second round of peering disputes. When all the major providers connected to the CIX, it was difficult for any provider not to peer because the CIX router always offered a way to exchange traffic. In less than three months, BBN, MCI and Sprint actions eliminated CIX as the router of last resort. It should be noted, UUNET has maintained its connection to the CIX router. Any provider interested in exchanging traffic with UUNET has always had the option of sending traffic via the CIX. This option does not exist for Genuity or Sprint. The fourth peering battle involved AGIS announcing its new peering policy at the least NANOG meeting held at the University of Michigan. It generated a lot of noise, but eventually AGIS's peering policy became irrelevant. Towards the end, AGIS was actively trying to get peering with new providers. The fifth peering battle involved UUNET. UUNET notified some number, I've heard between 10 and 20, providers UUNET would terminate their peering. At this time in the Internet's history only a few providers had written peering agreements. There were very few NDA's involved with peering before this time. It probably wasn't a breach of NDA, but someone leaked the story to the press. UUNET eventually was able to shutdown the story, but that lead to the next problem. Everything is a secret, so people imagine things were in peering agreements. The sixth peering battle involved once again BBN/GTE and the MCI/Worldcom merger. GTE worked very diligently to bring the issue of peering to the attention of regulators in the US and Europe. Eventually the EU Commission issued administrative inquires of all the major providers about the nature of the agreements, the amount of traffic, the types of connections and so forth. In the end, the nature of peering agreements wasn't clarified, but Worldcom had to spin off its InternetMCI division to Cable & Wireless. The seventh peering battle involved again BBN/Genuity/GTE and Exodus. This time it was the battle over imbalanced traffic flows. BBN and Exodus had a dispute, but it was settled and as they say on TV the terms were not announced. The imbalance issue has come up a few more times with other providers such as PSI, Abovenet and others. So, even though some folks like to point to UUNET as the big bully on the block, if you look at history; BBN has more often than not been the power behind the throne in these peering battles.

1 0

Re: How does one make not playing nice with each other scale? (Wa
by Paul Vixie 14 Jan '01

14 Jan '01

> I'll point out that someone banning a site for AUP violations should only be > able to affect their own network, since policies are supposed to be > organization-level. (Thus, inflicting your policy decision on someone else > is a very gray area, legally and ethically.) unless there's a bgp routing leak, in violation of both policy and intent, there is no way to inflict your policy decision on someone against their will. this is because all traffic in an AS is paid for by at least one party (the sender, or the recipient, or the agent of one or the other) who has a contract with the owner of the capital plant making up that AS. in AS6461's case, every customer agreement ever signed includes a binding reference to the AS6461 AUG. any traffic blocked by the AS's owner by way of enforcing that AUG is perfectly within that AS owner's rights. > ..., in this case, AboveNet is inflicting policy decisions on transit > routes =without consent=. (It's obvious this is without consent, > otherwise this thread would never have come up.) obvious to you perhaps, but incorrect nevertheless. the complainer has since had their contract read to them and has learned that they did in fact consent to this type of policy-related blockage, by signing agreement to that contract. -- Paul Vixie <pvixie(a)mmfn.com> CTO and SVP, MFN (NASDAQ: MFNX) AboveNet, PAIX, and MIBH are subsidiaries of Metromedia Fiber Network, Inc.

1 0

RE: How does one make not playing nice with each other scale? (Wa s: net.terrorism)
by Roeland Meyer 14 Jan '01

14 Jan '01

The consent comes from signing the service agreement and is built into the SLA. Yes, such anti-routing would need to be mentioned ... that is all. I am quite comfortable with AboveNet transit policies, as currently implemented. I have a number of clients, in AboveNet co-lo, that would be greatly inconvenienced were those policies (WRT ORBS) to change significantly. In fact, they are not yet secure enough to withstand the cracker attack wave that usually follows an ORBS listing. I know others, that are NOT clients, in the same shape. But, they are getting there. However, it takes time. -----Original Message----- From: Mathew Butler [mailto:mbutler@tonbu.com] Sent: Saturday, January 13, 2001 2:27 PM To: 'Mark Mentovai'; Paul Vixie Cc: nanog(a)merit.edu Subject: RE: How does one make not playing nice with each other scale? (Wa s: net.terrorism) I'll point out that someone banning a site for AUP violations should only be able to affect their own network, since policies are supposed to be organization-level. (Thus, inflicting your policy decision on someone else is a very gray area, legally and ethically.) The reason why MAPS-RBL works (and is legally protected) is because everyone who uses it must -consent- to using it, and take positive action on their end to configure it. This means that each organization generates and enforces their own policy, though with assistance from an outside consultancy. However, in this case, AboveNet is inflicting policy decisions on transit routes =without consent=. (It's obvious this is without consent, otherwise this thread would never have come up.) It brings up an interesting point, but the law has held in the past that boycotts are only effective and legal if they're voluntary, and if coercion is involved then it become "intimidation tactics" of "organized crime". I can't for the life of me imagine how the Internet is any different -- maybe if you tried to apply turnpike or private highway rules to it, but those rules are generally based on consent, as well. Just some thoughts... -Mat Butler -----Original Message----- From: Mark Mentovai [mailto:mark-list@mentovai.com] Sent: Saturday, January 13, 2001 10:26 AM To: Paul Vixie Cc: nanog(a)merit.edu Subject: Re: How does one make not playing nice with each other scale? (Was: net.terrorism) There are a few things that would stand in the way of adoption of something like this: first, each anti-route would require manual configuration, and that comes with its own set of problems. Another potential issue (this is purely theoretical, I'm not referring to any past, present, or future situation in particular) is that providers trying to blackhole a certain site for AUP violations may want to negatively impact reachability as much as possible, rather than purely keeping the offending traffic off their network. These folks wouldn't want to advertise anti-routes because the resulting blackhole avoidance would encourage others to take working alternate paths, which does less harm to the site in question. Still, this may be a beneficial, even if little-used, addition. Thoughts? Mark

2 1

Re: How does one make not playing nice with each other scale? (Was: net.terrorism)
by Paul Vixie 13 Jan '01

13 Jan '01

marcel(a)our.domaintje.com (Anne Marcel) writes: > There is no need to deaggregate the /16 that contain nullrouted /32's. > This information is (in this case) already available from AS7777 as a > multihop eBGP feed. Nope. No part of ORBS is listed in AS7777. The block which inspired this thread is completely private to AS6461 and has to do with that network's AUG.

5 5

RE: Online BGP study material for newbies
by Irwin Lazar 13 Jan '01

13 Jan '01

Hi, Please see www.itprc.com/routing.htm for several BGP materials. Also, the book "Internet Routing Architectures" by Basam Halabi is well worth reading. Irwin > -----Original Message----- > From: Lionel Lauer [mailto:longword@newsguy.com] > Sent: Friday, January 12, 2001 9:07 AM > To: nanog(a)merit.edu > Subject: Online BGP study material for newbies > > > > Per the subject line, could anyone recommend online sources of > information that would be helpful for a newbie (approx. CCNA level) > learning BGP? > Material that covers both common & best practices in a > Real-World-compatible manner would be especially helpful. > > -- > W > . | ,. w , "Some people are alive only because > \|/ \|/ it is illegal to kill them." Perna condita > delenda est > ---^----^----------------------------------------------------- > ---------- >

1 0

BGP Filtering
by Jon Stanley 13 Jan '01

13 Jan '01

I was assiting a customer the other day who was attempting to act as transit to us (we were filtering it thank goodness). Now my question is why the AS_PATH list that I gave him did not work. His AS is (let's say) 65000, and he has a transit AS 65001. He is multi-homed with AS1 and AS6347. Here is what I gave him: ip as-path access-list 20 deny ^.*(_6347).*$ ip as-path access-list 20 deny ^.*(_1).*$ ip as-path access-list 20 permit .* and I then applied it as a filter-list outbound on the neighbor. This worked great at filtering out the routes that he was originating. As for the routes that HIS transit customer was advertising, it didn't work at all - they weren't getting advertised. I thought that the access-list may have been defective, so i changed the second line to ^.*(_1_).*$ but that didn't help either. What I wound up doing as a bandaid was putting in ip as-path access-list 20 permit ^65001$ between the second deny and the permit .*. Now I may not understand Cisco regular expressions, but the first access-list the desired effect was to deny everything with AS1 or AS6347 in the as-path and permit everything else. Why didn't this work as intended? AS numbers changed to protect the innocent :).

3 2

net.terrorism
by Sabri Berisha 13 Jan '01

13 Jan '01

Hi, My name is Sabri. I'm just another dude involved in internetworking and I work for a small isp in The Netherlands. I am concerned. Concerned about people and companies who think they are in the position to be net.gods and for political reasons destroy the free character of the internet. In the history of the internet, people have been trusting each other. On the lower technical levels, great things like peering have been developed. At the various IX'es, commercial and non-profit companies exchange information about each others routes using BGP4 and various other routing protocols. In my opinion, announcing a netblock using BGP4 is making a promise to carry traffic to a destination within that netblock. If you feel that parts of that network are against your ethics or AUP, you should not be announcing such a netblock. If you do so, you will make a promise which you do not forfill. That is not a nice thing to do in a world which is based on trust and agreements between parties. I was shocked to find out that one of the larger transit providers (which the company I work for buys transit from) is actively violating the trust it has been given by the internetworld. Above.net is blocking a host in UUnet IP space. After finding out about this we notified Above.net in The Netherlands and asked what it was about and requested them to stop announcing the netblock if they would continue to nullroute the host involved. After various contacts about this matter, Above.net answered with the following statements (according to the salesdroid it came from Paul Vixie himself): > 194.178.232.55/32. --> this tester is part of a /16 belonging to > uunet, and sends traffic which is in violation of our AUG. we > complained to uunet without any effect. if we have blocked access > from this /32 to our backbone, we are within our rights. After this mail, we contacted Above.net again. They basically told us it was for our own protection because that traffic from that host does not comply to their AUP. We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response. More information and logs on http://www.bit.nl/~sabri/above/ -- /* Sabri Berisha * * CCNA, BOFH, Systems admin Linux/FreeBSD */

20 35

Cogent?
by Timothy Brown 13 Jan '01

13 Jan '01

I seem to remember reading some stuff about Cogent on NANOG a short while back, but I can't find it in cctec's archive. So my question is this: Cogent is advertising 100M for $1000 a month by bringing their own fiber into facilities. Does anyone have experience with Cogent? Can anyone tell me things like do they meet their install deadlines, is there anything peculiar about their network, etc. Thanks, Tim

2 1