May 1996 - Test - lists.nanog.org

Re: Worldly Thoughts
by John Curran 11 May '96

11 May '96

At 11:47 PM 5/10/96, Matthew Kaufman wrote: >I understand that nationwide providers don't want to provide me with >"free transit", so, I suggest the following solutions (directed at >those nationwide providers who don't peer with me, and networks like mine): > > 1. Peer with me anyway, but don't accept any of my routes into your > network... that allows me to do the same thing I would do if I were > nationwide and doing quickest-exit (feed all traffic destined for your > nationwide network into it at the west coast) without giving me the > benefit of the return path... this is no more asymmetric than we've got > now, and at least accelerates the one direction. I've got a transit > provider, so I'm going to hand you the very same packets eventually... > you might as well take them off my hands at the interconnect, rather > than have them presented to you by my transit provider. Interesting... it does avoid the transit issue, so it's worth considering to some extent. I'll note that the current west-coast interconnects are not exactly lacking traffic so there may be cases where it may not be advisable to peer anyway if adds more traffic to the interconnect. > 2. Even better, accept my routes into your network but only use them > within region... I know this isn't nearly as easy as #1, so I don't > expect it to happen, but it would be a significant performance benefit > for the local traffic your customers in the region are generating which > is headed towards me. Once outside the region, of course, you ignore the > direct routes from me and just give them to my transit provider. It becomes very entertaining to scale the above model (although it does provide an excuse to use nearly every BGP routing feature in IOS. :-) /John

1 0

Re: Worldly Thoughts
by matthew＠scruz.net 10 May '96

10 May '96

We have a transit connection here _and_ a connection to mae-west. The mae-west connection's best use is to get traffic to and from other medium-sized regional providers without visiting either our or their transit provider (often different ones, so we're saving a lot of hops and potential congestion points here) There's also those nationwide providers (like UUnet) who apparently find it in their best interest to peer with regional networks to take advantage of the increased performance that parties on both sides get when it happens. I think this makes for a lot of happy customers on both sides of the situation, because any increase in performance or reliability between my network and the nationwide network's customers translates into fewer complaints by those customers that "the net's broken today". Sprint had an engineer on the phone with our operations center just a couple days ago, trying to resolve a complaint originating with a Sprint customer that our network was unreachable... had Sprint been peering with us, instead of relying exclusively on our transit provider who happened to be having an outage, Sprint would have had a happier customer and that Sprint engineer wouldn't have had to make that phone call. Last I checked, paying a skilled NOC person for a few hours could pay for months worth of the bandwidth that we'd "get for free" if Sprint peered with us at just a single coast. The unfortunate thing is when regional providers turn into national providers and lose their incentive to peer with other regionals (eg. formerly-BARRNet, who isn't interested in peering with me because I'm only on one coast, even though, with quickest-exit, all the traffic between the west coast part of BBN Planet and our network would be crossing the west-coast interconnect only... seems silly for me to have to go buy a router and a DS3 to the east coast just so regional traffic can stay local and avoid the extra hops imposed by us each using our transit providers) I understand that nationwide providers don't want to provide me with "free transit", so, I suggest the following solutions (directed at those nationwide providers who don't peer with me, and networks like mine): 1. Peer with me anyway, but don't accept any of my routes into your network... that allows me to do the same thing I would do if I were nationwide and doing quickest-exit (feed all traffic destined for your nationwide network into it at the west coast) without giving me the benefit of the return path... this is no more asymmetric than we've got now, and at least accelerates the one direction. I've got a transit provider, so I'm going to hand you the very same packets eventually... you might as well take them off my hands at the interconnect, rather than have them presented to you by my transit provider. 2. Even better, accept my routes into your network but only use them within region... I know this isn't nearly as easy as #1, so I don't expect it to happen, but it would be a significant performance benefit for the local traffic your customers in the region are generating which is headed towards me. Once outside the region, of course, you ignore the direct routes from me and just give them to my transit provider. Meanwhile, the interconnect is still mighty useful for getting traffic around the area, so even without peering with everybody who's there, we see a lot of performance gains that our customers (and the customers of the other networks) appreciate. There's no way we can pick up all of the regional business, and I think most of our competition knows that they're in the same situation, and that's what makes regional peering work. -matthew kaufman matthew(a)scruz.net Original message <199605110144.VAA26028(a)neteng.nis.newscorp.com> From: Dave Curado <dcurado(a)neteng.nis.newscorp.com> Date: May 10, 21:44 Subject: Re: Worldly Thoughts > > > Or, possible some small providers buy a multi-megabit circuit from a > large provider who gives them transit. The small provider then connects > at a single NAP and picks up bilateral peering sessions with a bunch > of people there. The result is offloading traffic from their > "transit link", which stands a good chance of being priced as a > "burstable" link. (pay for what you use) That gives the small > provider an economic incentive to operate in this manner. > > No comment on whether this is a good idea or bad, but I understand > the thinking. > > davec > >-- End of excerpt from Dave Curado

1 0

Worldly Thoughts
by Alan Hannan 10 May '96

10 May '96

Pondering many things. Namely, the evolution of the Internet. Without respect for the many NAPs popping up (which is good), without respect for the lack of available bandwidth (which is bad), I am concerned about the evolution of our business. I'll state the obvious to establish a direction. In the beginning there were researchers, and they were good. They built a network, and it was extended to include core groups, and they also found it to be terribly useful. This was extended to Beta in the form of the NSFNet, managed by our friends at ANS and Merit, which gave rise to my neck of the woods, MIDnet, which provided me a passion and livelihood. Off goes the funding, off goes the backbone topology. Enter NAPs, and peering problems. Version 1.0. Oh joy. In the past, we were (excuse the metcalfesque) centrally managed, and issues of peering were resolved by one body. As we examine peering, we happen upon an inquisition into desire, and motivation. NSPs [Network Service Providers] (defined as anyone who is paid to connect some entity to another entity) found that they could go to a NAP or Meet Point, and gain access to everyone else. I can think of smallish turf battles, the CIX silliness, and the quarrels over what it really meant to be "on the Internet". At one point, it meant just to BE at the NAPs, as being at the NAPs implied that you could talk to everyone there. And then, just like Babylon, people stopped talking to each other. And so I view the future, unless things change. That's not to say I'm armageddonish, or even diluvian, just observant of the significant dynamic changes this is currently wreaking. So, WHY would an NSP enter into a peering agreement with another person? Why, to profit from the one side of the connection, to enable an entity [labeled A] to talk with some other entity [labeled B]. In most cases, NSP1 had as customer A, and NSP2 had as customer B, and obv. it was in their best interest to meet somewhere to talk to each other. NSP1 added value to A, by providing a path to B. NSP2 added value to customer B by providing a path to A. So, comes my curiosity, and my puzzling thoughts about the current state of the net. Why is it not in my best interest to talk to NSPX at a meet point? Why, when it is in MY customer's best interest to talk to EVERYONE, would I not converse, and share knowledge and invitations about my customer base? My thought, conspiratorally, is that larger folks (NSP4) could care less about talking to NSP3's p% of the net, when there is a lower cost involved in talking to NSP4's q% of the net, assuming q >>> p. And yet, I fail to grasp why it is not in their best interest to still include that group located in p%, NSP3's customers. Perhaps because they'd rather have the customers? I'd appreciate hearing the rounds of explanation why larger NSPs don't want to talk w/ smaller NSPs. Just because someone has 30% of the internet, they still have an interest in connecting their 30% of the net to .1% of the net, no? Perhaps the geographic cost investment in transit to far-reaching customers is sufficient. Somehow that doesn't answer the question for me. I'm not talking about transit, I don't think it's necessarily in NSP3's interest to carry NSP4's traffic to NSP1. But NSP3-NSP4 I can see as beneficial, w/ no dalliance. -alan "baring my heart for the wrath of all"

6 6

Re: Worldly Thoughts
by Dave Paulsen 10 May '96

10 May '96

On 9 May 96 at 22:09, Alan Hannan wrote: > And yet, I fail to grasp why it is not in their best interest to > still include that group located in p%, NSP3's customers. Perhaps > because they'd rather have the customers? [pessimistic mode on]...that's kinda my gut level feeling, considering the way some of the national providers, and recent announcements by some of the RBOCs, tend to lead the uninitiated to believe the only way to reliably connect in a time sensitive and cost effective manner is with the big boys. _dave_(seemingly obligatory and definitely bandwidth wasting .sig)

1 0

Out of date contact information
by Sean Donelan 10 May '96

10 May '96

I hate to interrupt the ongoing discussion about peering, but I'd like to bring up another perennial topic, out-of-date network contact information. The larger, and older the company the harder it is to find the right contact person. Sure there are lots, and lots of lists; WHOIS at the InterNIC, lists kept by various NAP operators, even in in-addr.arpa TXT records. So many lists people have difficulty knowing what to update when people's responsibilities change. Suppose I wanted to find out Sprint's real policy this week, or a government agency network such as ESnet's Internet policy; who would I contact? The listed contact names don't seem to work, or are out-of-date. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

20 32

RE: Worldly Thoughts
by owen＠DeLong.SJ.CA.US 10 May '96

10 May '96

> >From: Erik Sherk[SMTP:sherk@uunet.uu.net] > > >> From: David Schwartz aka Joel Katz[SMTP:stimpson@stimpson.igc.net] > >> Let's look at a hypothetical situation. ISP1 peers at MAE-E and > >> buys transit from MCI there. Now they ask Sprint to peer with them. > Let's > >> look at how they reach sites on the west coast. > > > >This is a violation of the rules of Mae-East: it is not to be used for > >customer connections. ISP1 must have a private connection to MCI. > > > >Erik > > Are you saying that MFS will not allow a private connection between two > routers located at the MAE facility, even if the connection is _not_ made > using the MAE FDDI switch, but is instead a direct (e.g. HSSI or AIP) > connection between the two routers?? If so, I haven't seen any > documentation to that effect... > -- > Jim Browning > > > I interpret it slightly differently. I think he is saying that if you buy transit from MCI, you can't do it across MAE East, but instead would need a private connection to MCI. Presumably this could be done at the MAE East site, as long as it did not congest the MAE East net. Owen

1 0

RE: Worldly Thoughts
by Jim Browning 10 May '96

10 May '96

>From: Alan Hannan[SMTP:alan@gi.net] > Pondering many things. I have certainly been trying my best to gain as complete an understanding of these 'things' as I possibly can while constructing a backbone, and so will offer my (hopefully not _too_ clueless) thoughts: > Why is it not in my best interest to talk to > NSPX at a meet point? > > My thought, conspiratorally, is that larger folks (NSP4) could > care less about talking to NSP3's p% of the net, when there is a > lower cost involved in talking to NSP4's q% of the net, > assuming q >>> p. > > And yet, I fail to grasp why it is not in their best interest to > still include that group located in p%, NSP3's customers. Perhaps > because they'd rather have the customers? Perhaps NSP4 believes (likely correctly) that NSP3 will pay NSP4 (or someone peering with NSP4), to ensure that NSP3 customers can talk to the (larger set of) customers served by NSP4? > Just because someone has 30% of the internet, they still have an > interest in connecting their 30% of the net to .1% of the net, no? Or expect the .1% to find a way to them? > Perhaps the geographic cost investment in transit to far-reaching > customers is sufficient. Somehow that doesn't answer the question > for me. > I'm not talking about transit, I don't think it's necessarily in > NSP3's interest to carry NSP4's traffic to NSP1. But NSP3-NSP4 I > can see as beneficial, w/ no dalliance. Clearly this issue is rooted in economics, involving costs (including the labor costs involved in maintaining what would be a large number of peering relationships) as well as the maximization of revenue potential. We have lost prospective customers because of our lack of NAP peering relationships, when the customer hadn't the faintest idea what the concept meant ("asking if we "paired" with anybody). My mental image of the whole picture is that, if NSP4 is going to accept traffic from a West Coast customer of NSP3 and haul it to their East Coast customer, they expect to be able to hand the return traffic back to you on the East Coast, not haul it to a single peering location in one part of the country. This is not transit in the sense that it crosses into other networks, yet it certainly requires the use of national infrastructure. I'm not sure this answers the question fully for me, either. > -alan > > "baring my heart for the wrath of all" May it bring us all closer to cluefullness... :) -- Jim Browning

1 0

FWD: Pacific Bell's LA NAP in service
by Kent W. England 08 May '96

08 May '96

Pac Bell has announced their LA NAP is operational. Contact and details below. --Kent ---------- I am pleased to announce that Pacific Bell has installed, tested and is ready for service at our LA NAP. If you are interested in service in the LA area please contact your Pacific Bell account representative or respond via email to nap-info(a)PacBell.com. The Los Angeles area StrataCom BPX ATM switch is designated HLWDCA01, located at 1429 N. Gower Street, 2nd floor, Hollywood, California. The NPA NXX information is 213 468. Initial service will be at the DS3 rate. With our upgrade to StrataCom's BPX release 8.1, scheduled for June '96, we will offer OC3c UNI access in both LA and Bay Area NAPs. NAP service continues to be offered under a California Public Utilities Commission approved Market Trial. Jim J. P. Diestel Director Internet NAP Marketing 510-824-7244 jpdiest(a)popper.pacbell.com

4 3

RE: FWD: Pacific Bell's LA NAP in service
by Jim Browning 08 May '96

08 May '96

>From: Matthew Kaufman[SMTP:matthew@scruz.net] >From: bmanning(a)isi.edu (Bill Manning) >> > On Tue, 7 May 1996, Kent W. England wrote: >> > >> > > Pac Bell has announced their LA NAP is operational. Contact and details below. >> > >> > Is there not already a MAE-LA? Why would thay have an LA NAP if even >> > MAE-LA hasn't taken off as of yet? >> > >> > Just a question. >> > >> > Christian Nielsen >> >> Yes, there is. I would expect that the NAP service is offering >> is an extention of the existing BayArea service. This approach >> reduces the cost of entry of entry for people you are in the So.Cal. >> area to a local loop charge. >> It appears that thye believe that a "distributed" service is >> more effective than two seperate exchanges. >As far as I know, PacBell wouldn't be permitted to extend PVCs between >the LA NAP and the SF NAP I have had several discussions with PacBell concerning NAP connections to both sites, and at no time have they indicated the ability to provide connectivity between them. To the best of my knowledge, they look at the two (SF and LA) as separate facilities. They are both 'virtual meet points' which utilize ATM connections into the PacBell cell relay clouds, but these clouds are isolated - they do not extend beyond the borders of each LATA. They expect you to obtain a circuit _into_ the LATA from an IXC. -- Jim Browning

1 0

Re: FWD: Pacific Bell's LA NAP in service
by matthew＠scruz.net 07 May '96

07 May '96

Original message <199605072153.AA13332(a)zephyr.isi.edu> From: bmanning(a)isi.edu (Bill Manning) Date: May 7, 14:53 Subject: Re: FWD: Pacific Bell's LA NAP in service > > > > > On Tue, 7 May 1996, Kent W. England wrote: > > > > > Pac Bell has announced their LA NAP is operational. Contact and details below. > > > > Is there not already a MAE-LA? Why would thay have an LA NAP if even > > MAE-LA hasn't taken off as of yet? > > > > Just a question. > > > > Christian Nielsen > > Yes, there is. I would expect that the NAP service is offering > is an extention of the existing BayArea service. This approach > reduces the cost of entry of entry for people you are in the So.Cal. > area to a local loop charge. > It appears that thye believe that a "distributed" service is > more effective than two seperate exchanges. > > > -- > --bill >-- End of excerpt from Bill Manning As far as I know, PacBell wouldn't be permitted to extend PVCs between the LA NAP and the SF NAP -matthew kaufman matthew(a)scruz.net

1 0