- Test - lists.nanog.org

Re: NAP Solutions
by Tim Salo 14 Nov '97

14 Nov '97

> Date: Fri, 14 Nov 1997 10:57:39 -0500 (EST) > From: Brian Horvitz <horvitz(a)shore.net> > To: nanog(a)merit.edu > Subject: NAP Solutions > > Has anybody though about a packet over sonet solution for an exchange? > Seems like you could get a pretty effective answer out of a GSR with OC3 > and OC12 interfaces... I think your question provides an interesting opportunity for comparing SONET solutions with, for example, ATM solutions. First, some thoughts on a local-area interconnect. If you want a fully-meshed interconnect, you will need n-1 SONET interfaces on each router, when "n" is the number of routers at the interconnect, [assuming one router per ISP]. You might feel that this is an excessive number of router interfaces, (assuming n > 2), so you might consider creating a ring instead. In this case, each router would require only two interfaces. However, most packets will need to be forwarded through several routers before reaching their final destination [within the interconnect]. As a result, a certain amount of the capacity of your router and your interfaces will be used to forward packets between your competitors. Obviously, there is a spectrum of configurations between a full mesh and a ring. However, determining the best trade-off between the cost of additional interfaces, additional bandwidth used to forward packets between routers not directly connected, and additional routing capacity to forward packets within the interconnect is probably worthy of a Master's thesis. (Of course, you might have to write another thesis every time you add another router to the interconnect. Creating a general solution might be worthy of a Doctoral dissertation.) [Note that this assumes that no router vendor integrates a SONET mux into the router. As far as I know, no router vendor has an integrated SONET mux.] Using an ATM switch (or most any other switch, for that matter) has a number of advantages. First, each router needs only one interface to the interconnect. This interface should probably be as large as the router can support. (This is the problem facing many of the existing interconnects, namely that the router can support more than 100 Mbps, but the interconnect media runs at only 100 Mbps.) Second, adding additional routers is fairly straight-forward, (e.g., you don't have to add another SONET interface to every existing router, in the rather unlikely event that you have a full-mesh topology). Rather, you merely plug the new router into the switch. Finally, adding additional capacity is probably a lot easier. Each router [ATM] interface can be upgraded as that router requires additional capacity. For example, an interconnect could simultaneously support both OC-3c and OC-12c connections. In a similar fashion, the aggregate capacity of the interconnect can be increased by swapping in a new ATM switch, (rather than, for example, swapping out the FDDI interfaces on the routers for gigabit ethernet interfaces). Now, there is a certain price for using ATM rather than SONET, namely the overhead incurred by ATM. However, as I have said before, the best decision criteria is an analysis of cost/performance, not merely looking at overheads. In this case, you would need to compare the cost of the unnecessary SONET interfaces with the cost of the bandwidth used for ATM. So, it seems to me that SONET makes sense for a private interconnect between two parties, but that a switched technology, such as ATM or perhaps gigabit ethernet, makes sense when the number of parties is greater than two, (like three, for example). Now, this same analysis can be applied in the wide area. The next question is, if you have decide to use ATM, whether to create a local interconnect, (i.e., put the switch and all the routers in one room) or to create a distributed interconnect, (e.g., leave the routers distributed throughout a LATA or even throughout the country). I think there are a number of good arguments both ways. Both local interconnects and intra-LATA interconnects have been tried. I don't know of anyone who has created a nationwide interconnect, (although I think all of the original NAP proposals suggested nationwide NAPs). On the other hand, the question of SONET versus ATM in a wide-area environment is still being explored in, for example, the Internet2 efforts. I don't understand how wide-area SONET solutions are supposed to scale, but perhaps someone will figure it out. Of course, another interesting question is why, with services like ATM with distance-insensitive pricing, one would build a regional wide-area interconnect (e.g., a regional, wide-area gigapop), rather than a nationwide interconnect. (Note that some claim that propagation delays are an issue in a nationwide interconnect, but I believe that, e.g., routing through the opposite coast to get to the adjacent city, would result from poor design or configuration, rather from any inherent defect in the concept of nationwide interconnects/gigapops). Wide-area SONET certainly has its place, depending on the relative price of SONET versus ATM services, the number of locations which need to be interconnected and the amount of bandwidth required. For example, in a campus environment where private fiber is available, point-to-point SONET solutions are easier to justify than when you need to lease SONET links from a carrier. Hopefully, projects like Internet2 and NGI will explore both SONET and ATM wide-area interconnects so we can gain a better understanding of their advantages and capabilities. And finally, I don't know if I answered you question. But, if you do decide to build a SONET interconnect, please let us know how it works. -tjs

3 3

Re: NAP Solutions
by Tony Li 14 Nov '97

14 Nov '97

> Has anybody though about a packet over sonet solution for an exchange? As a matter of fact, yes. A SONET MPLS switch makes for a very interesting exchange. The use of MPLS avoids having the box act as a router and thereby avoids the headaches of figuring out just which routes the exchange should select. If the label switched paths in the switch are manually configured, there's no easy way for a non-neighbor to "accidentally" send you traffic. The switch fabric scales up nicely in that there is an interesting selection of link speeds that promise to scale up for the forseeable future. You can scale the fabric up either by growing individual switches, or by creating a switch fabric, or both. Sites connecting to the switch can do so remotely by bringing in a SONET link, so no on-site equipment is necessary. In short, technologically, a SONET MPLS exchange is a fine alternative because it provides the architectural advantages of a switched fabric without the bandwidth limitations of LAN technologies and without the cell loss problems of ATM. Note that this probably does not fix the economics and politics of the exchange point. Those are almost orthogonal issues. Tony

1 0

Announcing new route (What besides BGP?)
by Forrest W. Christian 14 Nov '97

14 Nov '97

Ok, I've got my BGP4 announcement configured for my new /19 which I feel much better about after the response I got from this list (thanks for all that replied). I'm now waiting for inbound filter changes on my upstream BGP sessions. Once upon a time, I used to also have to enter a new route into the raddb. Unfortunately, it's been some time since I have done that and am uncertain of the state of the raddb and whether or not it is still in use. Or, if it has been replaced/supplemented with something else. Is there a FAQ I should have bookmarked which contains this information? Or, if there isn't could someone point me in the right direction? Thanks again, -forrestc(a)imach.com

9 10

The Cidr Report
by Tony Bates 14 Nov '97

14 Nov '97

1 0

Re: GTE to acquire Genuity
by ccook＠netasset.com 14 Nov '97

14 Nov '97

> And when that happens, Microsoft will buy Worldcomm. And then Microsoft > will require AOL to use MSN's interface bundled with Worldcomm's > connectivity or get no connectivity at all. Shhhh. Don't give the Evil Empire any ideas.... Chris Cook Network Engineer __________________________________________________________________________ Net Asset Network Operations Center 1315 Van Ness Ave., Suite 103 Fresno CA 93721 209/225-0222

8 9

Re: GTE to acquire Genuity
by George J. Broadfoot III 14 Nov '97

14 Nov '97

Of course being all public companies one can go to www.sec.gov and read the filings of each and get the specifics of what is owned by who. George J. Broadfoot III VP of Operations Laser Link Network Services, Inc. 610.566.2993 > >typical nanog bitter-batter: making assumptions based upon half >truths.

1 0

NAP Solutions
by Brian Horvitz 14 Nov '97

14 Nov '97

Has anybody though about a packet over sonet solution for an exchange? Seems like you could get a pretty effective answer out of a GSR with OC3 and OC12 interfaces... Brian Horvitz

1 0

Press-Release: Support model of the Internet Service Providers for the DFN/WIN is discontinued - German WiN links are shut down
by Winfried Haug 14 Nov '97

14 Nov '97

Hello. First sorry for the long e-Mail, but what happens in Germany now will affect the whole community and therefor i think you should read this mail :-) This press-Release is also available at http://www.decix.de/winpresseE.html. Information about the decix can be found at http://www.decix.de. Thank you for your patience --- Winfried Haug - Sprecher AK-DECIX im ECO e.V - Chair of AK-DECIX within ECO e.V For more information about the only neutral Germany Exchange Point DE-CIX please visit http://www.decix.de. The ECO Homepage may be found at http://www.eco.de If you want more information about joining DE-CIX please contact: sprecher(a)decix.de ------------------------schnipp-------------------schnipp--------------------- PRESS RELEASE COMPANY NEWS Support model of the Internet Service Providers for the DFN is discontinued German WiN links are shut down Germany, November 1997. The leading German Internet Service Providers (ISPs) are ending the current voluntary support of the German science network (WiN) link to the commercial Internet landscape. The deadline has been set for 31 December 1997. In order to avoid a data exchange between the WiN and the commercial networks via international links which is cost-intensive for the tax-payer, the commercial Internet providers, at the suggestion of the DFN association, are offering a central exchange point as the new support model. Past support of the academic sector of the Internet Historically, the commercial network and the part of the Internet used for scientific purposes in Germany were based on different infrastructures. The commercial Internet providers support the link of the academic network (WiN) to the commercial Internet landscape. The millions needed annually for the financing of this support is voluntary and one-sided by the commercial Internet Service Providers (ISPs). Discontinuation of the present support model at the end of the year The growing range of demand and the rising amount of access to commercial Internet contents from the WiN side is leading to a cost explosion of the current model. For this reason the ISPs will adapt their support of the DFN at the end of the year. As a result of the planned shutting down of the direct connection between the German ISPs and the WiN, in future data will be exchanged between the networks exclusively via international connections in the USA. For the ISPs this will lead to better capacity use of the international lines and evens out the current surplus net traffic from the USA to Germany. The international link of the WiN would be put under a lot of pressure by the joint additional traffic of its USA subscribers, which will lead to a price increase for the international link. This will have to be financed by tax revenue, which DFNs WiN instigates by the state. In order to measure the precise effects a shut down will have on the traffic flow, the German ISPs will shut down their connections to WiN on 25th November 1997 at 12 oclock for a trial period of 24 hours. Favoured solution by support model of a self-financing exchange point A new support model is currently being discussed by the commercial ISPs. This model allows for the setting-up of a central exchange point in Germany for the traffic between the German scientific network and the commercial networks. The setting-up and development of the tie would be sponsored by the ISPs with a one-off knock-on financing in the region of almost one million Marks over a two year period. The exchange of traffic via this type of connection point would ease the burden on the tax-payer by about six million Marks every year. This support model will be presented to the committee of the DFN and all its members in an open letter within the next few days. Undersigned Internet Service Providers Gerfnet Germany, Compuserve Network Services, GTN (Deutsches Provider Network), ECRC, Interactiv Networx, IS Internet Services, mediaWays, Nacamar, NetUse, NTG/Xlink, POP Point of Presence, Seicom, Spacenet, TCP/IP Contrib.net, UUNET Deutschland

1 0

Re: Well done Sprint!
by Scott Huddle 14 Nov '97

14 Nov '97

Which is just *too* bad, as we were able to glean marketing stats about their network while they had this information ;) [from a long time ago...] Sprint Speed Count % of % of Customers Bandwidth 45000000 15 0.7% 25.8% 12360000 0 0.0% 0.0% 10200000 0 0.0% 0.0% 10000000 0 0.0% 0.0% 8048000 0 0.0% 0.0% 6000000 0 0.0% 0.0% 5000000 6 0.3% 1.1% 4500000 0 0.0% 0.0% 4000000 0 0.0% 0.0% 3088000 0 0.0% 0.0% 3072000 0 0.0% 0.0% 3055000 0 0.0% 0.0% 3000000 0 0.0% 0.0% 2048000 4 0.2% 0.3% 2000000 0 0.0% 0.0% 1544000 1117 55.5% 65.9% 1472000 0 0.0% 0.0% 1408000 2 0.1% 0.1% 1344000 13 0.6% 0.7% 1024000 0 0.0% 0.0% 768000 23 1.1% 0.7% 640000 4 0.2% 0.1% 512000 65 3.2% 1.3% 448000 4 0.2% 0.1% 384000 54 2.7% 0.8% 256000 178 8.8% 1.7% 224000 0 0.0% 0.0% 128000 105 5.2% 0.5% 112000 0 0.0% 0.0% 64000 395 19.6% 1.0% 56000 0 0.0% 0.0% Total 2014 100.0% 100.0% Total subscription 2.62Gb Nice while it lasted ;) -scott > From owner-nanog(a)merit.edu Wed Nov 12 18:13 EST 1997 > X-Authentication-Warning: aegis.noc.telalink.net: rmc owned process doing -bs > Date: Wed, 12 Nov 1997 16:58:31 -0600 (CST) > From: Bob Collie <rmc(a)telalink.net> > X-Sender: rmc(a)aegis.noc.telalink.net > Reply-To: Bob Collie <bob.collie(a)telalink.net> > To: "Neil J. McRae" <neil(a)domino.org> > cc: nanog(a)merit.edu > Subject: Re: Well done Sprint! > X-Mailer: BobMail 1.0 (based on Pine 3.95) > MIME-Version: 1.0 > Sender: owner-nanog(a)merit.edu > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 1344 > > Although it appears that they have dropped off the link speed, etc > and interface from the name... > > > Aaah... > > -Bob > > > On Wed, 12 Nov 1997, Neil J. McRae wrote: > > > > > Wee after only about a year Sprint have lost the "/"'s! > > > > traceroute to www.sprint.net (204.117.214.13), 30 hops max, 40 byte packets > > 1 router (194.70.50.129) 1.397 ms 1.2 ms 3.505 ms > > 2 gin-nyy-ac1.Teleglobe.net (207.45.199.245) 83.074 ms 82.97 ms 82.858 ms > > 3 sl-gw16-pen-2-0.sprintlink.net (144.228.164.61) 85.841 ms 85.247 ms 85.274 ms > > 4 208.28.7.25 (208.28.7.25) 103.272 ms 96.141 ms 88.932 ms > > 5 sl-bb6-pen-4-0-0.sprintlink.net (144.232.0.77) 87.373 ms 101.192 ms 94.284 ms > > 6 sl-bb3-pen-4-0-0-155M.sprintlink.net (144.232.0.73) 90.893 ms 86.522 ms 90.032 ms > > 7 sl-bb2-dc-5-0-0.sprintlink.net (144.232.8.2) 91.378 ms 90.434 ms 92.114 ms > > 8 sl-s1-dc-0-0.sprintlink.net (144.228.20.121) 92.608 ms 92.737 ms 92.398 ms > > 9 ftp.sprintlink.net (204.117.214.13) 98.038 ms * 90.365 ms > > > > -- > > Neil J. McRae. Alive and Kicking. Domino: In the glow of the night > > neil(a)DOMINO.ORG NetBSD/sparc: 100% SpF (Solaris protection Factor) > > Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A> > > > > -- > Bob Collie, VP/Chief Technical Officer, Telalink Corporation > mailto:bob.collie@telalink.net > >

6 5

new facility for nanog mailing list
by Richard Welty 14 Nov '97

14 Nov '97

in light of the ongoing discussions about what kind of subject matter is appropriate to the nanog mailing list, i have completed development of an "autoflamer" intended to detect any inappropriate postings to nanog and generate a suitable obnoxious response. in light of the difficulty of determing appropriateness of postings to nanog, it appears that all postings to nanog will have to be "autoflamed". this facility will be enabled on April 1st, 1998. cheers, richard -- Richard Welty Chief Internet Engineer, INet Solutions welty(a)inet-solutions.net http://www.inet-solutions.net/~welty/ 888-311-INET

3 2