July 2001 - Test - lists.nanog.org

RE: Broadwing
by Miller, Steve 27 Jul '01

27 Jul '01

dial, dedicated?? which are you looking for? -steve -----Original Message----- From: Hansel E. Lee Jr. [mailto:hansel.lee@corp.winfirst.com] Sent: Friday, July 27, 2001 9:59 AM To: nanog(a)merit.edu Subject: Broadwing Sensitivity: Confidential All, I'm considering using Broadwing for some IP transport and am interested in hearing feedback from anyone else who is currently using them. Reliable/Unreliable, Good service? Hansel E. Lee Jr. Director of IP Engineering Western Integrated Networks, LLC ( WINfirst <http://www.winfirst.com> ) 2000 S Colorado Blvd, 2-800 Denver, CO 80222 (303) 407-1685 (office) (303) 601-1174 (cell) (978) 246-0378 (fax)

3 2

IXP Map..?
by D2 27 Jul '01

27 Jul '01

Hey guys - Can any one help? I am trying to find out if anyone has a Geographical World Map (gif bmp etc) with all the Public IXPs IX MAE etc marked on it. Search engines tell me that www.ep.net is the place to go, but sadly it seems to have been a place which is now gone...(!) telegeography has a great text list, but I wondered if anyone has a globe map.. My realworld geography is bad and it will take ages to locate all 200 IXPs and mark them out! I am sure it is something already done and wonder if any NANOG folks can help.. :) Dom Robinson : D2 Consulting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 'data in motion' ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IP Distribution Consultancy eMail: d2(a)d2consulting.co.uk www.d2consulting.co.uk (Also for Global-MIX ltd)

5 5

Re: NAP History (was RE: The large ISPs and Peering)
by Sean Donelan 26 Jul '01

26 Jul '01

On Thu, 26 July 2001, Robert E. Seastrom wrote: > At the time, the "center of the universe" was AS690, which was paid > for by US taxpayer money and consequently had an AUP. The NAPs were > envisioned as a transitional mechanism away from that arrangement. A > lot of us at the time wondered aloud why NSF needed to provide a stamp > of approval on US-based exchange points, as the FIXes, MAE East, and > Milo's setup at NASA-Ames were already going concerns without any kind > of endorsement from the NSF. Some companies (notably UUnet) thought > this was gratuitous enough that they never showed up at any NAPs. If I recall, the objection was to using ATM for a exchange fabric, because several people thought it was less reliable at the time. I thought UUNET was at the New York NAP (SPRINT Pennsauken, NJ) as well as the MAE-East alternate NAP, which used FDDI. There were several ISPs at that time which only connected to FDDI/Gigaswitch based exchange points, and shunned the ATM exchange points.

3 2

Discovering AS Path confederation...
by Chris Rapier 26 Jul '01

26 Jul '01

I was wondering if anyone knew how to do as path confederation discovery. Let me explain... I'm plotting observed traffic against BGP reported AS paths to get a logical view of traffic flow in a smallish network (I2). However, it was pointed out to me (by Bradley Huffaker) that the BGP reported path does not always correspond to the ASes a packet actually traverses. He provided me with some skitter data and routing table archives and I was able to confirm this on both his data and my own data. My contention is that the vast majority of this seeming divergence is the result of AS confederation and not any specific failure of the protocol (or implementation) as a whole. However, in light of what I am trying to do for my research, its important that I have more than a gut feeling to back up this claim. What I was thinking of doing was to collect a large number of traces and their corresponding traversed ASes and run statistical analysis on it to infer the confederations. If these confederations are mostly stable then I can say the observed divergence corresponds to this previously seen path. E.g.... I run a trace and find it traverses 701 702 8414 2912 7262 101 while the route table indicates its path should be 701 7262 101. If I know that 701 is confederating 8414 and 2912 then I know that the actual path corresponds to the routing table. However, I first need to determine that UUnet if actually doing that. At this point I'm stuck on that step and could use any pointers or insights people might have. Obviously, the best thing would be a paper that has already done exactly this so I can move on but I'll take anything. :) Chris Rapier

4 5

Re: NAP History (was RE: The large ISPs and Peering)
by Sean Donelan 26 Jul '01

26 Jul '01

On Thu, 26 July 2001, steve wolff wrote: > With the impending closure of the NSFNET Backbone, and the distfribution of > those funds to (academic) regional networks for the purpose of buying > backbone service from ISPs on the open market, NSF feared that universal > connectivity within the US higher education community might be lost - if all > ISPs concerned did not peer with one another. The NSF never required ISPs peer with one another. The requirement was to "connect" to the three primary NAPs, not exchange traffic. Universal connectivity was an issue we are still dealing with. > Accordingly, NSF established the NAPs as open exchange points, and the funds > distributed to regional networks to buy backbone service had a string > attached: the regionals could only buy from ISPs who agreed to come to one > or more NAPs and exchange higher ed traffic. Thus the universal connectivity > of the community NSF was charged to serve was aassured. The CIX router had a mandatory peering policy, assuring universal connectivity among its members. For several years, the CIX router served as the "router of last resort." But some providers didn't like that policy. Neither MAE-East, or the NAPs had "AUPs" covering traffic exchange. > NSF never intended the NAPs to be the ONLY peering/exchange points, and never > contemplated a 'stamp of approval' (or disapproval, for that matter) for > anybody else's exchange point; the NAPs were inclusive, not exclusive.

2 1

Re: NAP History (was RE: The large ISPs and Peering)
by Sean Donelan 26 Jul '01

26 Jul '01

On Thu, 26 July 2001, "Nipper, Arnold" wrote: > Sean Donelan schrieb: > > > exchange points. Some of the additional exchange points have grown very > > large, such as CIX, MAE-West, LINX, AMS-IX, even though they didn't have > > NSF's "stamp of approval." > > > > Why should LINX, AMS-IX, DE-CIX or any other European IXP need NSF's "stamp > of approval"? I don't think european, japanese, or even other US IXP's require NSF's "stamp of approval." I was pointing out there are a number of IXP which were not created by NSF's process. But some folks think "NAP" refers only to the NSF identified exchange points, and unless the government approves your NAP, there is some type of anti-trust issue with ISPs deciding to exchange traffic at a non-NSF NAP. I don't think that is true. The NSF stopped funding all the NAPs several years ago. Other than a historical oddity, there is nothing different about the NSF NAP and non-NSF exchange points.

1 0

update frequencies in routing protocols
by srihari varada 26 Jul '01

26 Jul '01

Hello All: I would appreciate, if some one could provide me with the routing table update frequencies that are typically configured for the BGP-4 and OSPF protocols. Regards, Srihari Varada

1 0

Re: 'we should all be uncomfortable with the extent to which luck..'
by Marshall Eubanks 26 Jul '01

26 Jul '01

> This is, in fact, what we do; it still makes me nervous. Marshall > > >On Wed, 25 Jul 2001, Marshall Eubanks wrote: > >> >> > >> > >> >>> > How many of us here run anything less than SSH and even allow telnetd >> to >> >>> > live on any of our hosts? >> >> Hey, we have had to do without SSH in more than one CISCO IOS build in the last >> 6 months in 12.1 / 12.2. >> >> This always made me feel very nervous. >> > > > > One way of avoiding this is to always have a console server that has >SSH implemented into the IOS build ( or even a separate vendor that >supports SSH ). This way you centrally access your network devices from >one spot, authenticated by SSH, if any of the devices in question do not >support SSH ( yes this can be impractical, but I typically want to have >console access to every device I administer if possible anyway ). > > > >.z > Marshall Eubanks tme(a)21rst-century.com

1 0

Re: NAP History (was RE: The large ISPs and Peering)
by rs＠seastrom.com 26 Jul '01

26 Jul '01

"Nipper, Arnold" <arnold(a)nipper.de> writes: > Sean Donelan schrieb: > > > exchange points. Some of the additional exchange points have grown very > > large, such as CIX, MAE-West, LINX, AMS-IX, even though they didn't have > > NSF's "stamp of approval." > > > > Why should LINX, AMS-IX, DE-CIX or any other European IXP need NSF's "stamp > of approval"? At the time, the "center of the universe" was AS690, which was paid for by US taxpayer money and consequently had an AUP. The NAPs were envisioned as a transitional mechanism away from that arrangement. A lot of us at the time wondered aloud why NSF needed to provide a stamp of approval on US-based exchange points, as the FIXes, MAE East, and Milo's setup at NASA-Ames were already going concerns without any kind of endorsement from the NSF. Some companies (notably UUnet) thought this was gratuitous enough that they never showed up at any NAPs. ---Rob

2 1

RE: The large ISPs and Peering
by Roeland Meyer 26 Jul '01

26 Jul '01

There is the larger problem of anti-trust issues. Those large providers collectively represent more than 60% of the market. I believe that this is the real basis of the concern. Such an arrangement could be construed as being anti-competitive. Were IBM to make such an arrangement with IBM and AT&T then DOJ might become very active. The same holds true here. Companies holding such large market-share control cannot quite do things the way that they want because we (collectively) have made laws that have deemed such activities as public-policy effecting activities and subject to some regulation, by public bodies. I don't see where that has changed. Even in the spirit of telcom co-opetition, such activity can still be construed as collusion. I'm suprised that their lawyers let them do that. Also, the past 30-years of track-record clearly shows that such activity cannot be kept secret. > -----Original Message----- > From: Jeff Aitken [mailto:jaitken@aitken.com] > Sent: Thursday, July 26, 2001 10:16 AM > To: Curtis Maurand > Cc: nanog(a)merit.edu > Subject: Re: The large ISPs and Peering > > > > On Thu, Jul 26, 2001 at 11:21:54AM -0400, Curtis Maurand wrote: > > A rose by any other name... The fact is, and history shows > us, that > > when cartels form, things get bad for the consumer. [...] > > However, The placement of the NAP's is disconcerting, because > > the process for choosing them was closed. > > This makes absolutely no sense. Are you saying that uninvolved > parties should be able to dictate where and how large "promising > local ISPs" should interconnect? Maybe we should have a vote on > NANOG! > > "How does this choice of interconnection point make you feel?" > > > > Does it make sense for all of > > my traffic going to maine.rr.com from lamere.net (both in > Maine and in > > the same communities) to exchange traffic at MAE east 650 > miles away? > > There's nothing preventing your provider from establishing additional > regional peering where appropriate; if they fail to provide the level > of service that you require you should vote with your wallet > and select > another provider. > > > > There won't be if the Tier-1's all form a "consotium." > > They will collude on network build out and stop competing [...] > > If the "consortium" is formmed it will wipe out all those > strides [...] > > A consortium will wipe out the glut and raise prices. > > The consortium will control supply at a lower level. > > Prices will increase. > > Yes, but the equalization will happen at the higher price. > > There's nobody to compete with, so why keep the price down? > > If you think that's not true, think again. > > Proof by repeated assertion, eh? > > I'm really confused here. How did we go from "certain large ISPs > are working together to reduce the cost of interconnection amongst > themselves" to "there will be no competition between these large > providers?" > > > --Jeff >

1 0