- NANOG - lists.nanog.org

Re: Funding for NAPs...
by jgs＠aads.net 08 Oct '95

08 Oct '95

At 11:02 PM 10/6/95, Dave Siegel wrote: >The NAP providers (Ameritech, Sprint, and PacBell) do get some government >money. As with all government funding, there is red tape, such as >providing services to R&E type stuff. Ameritech doesn't receive any government funding for the Chicago NAP. I believe that Bellcore receives some government funding. I don't think that Sprint or PacBell get any government $$ either, but they should confirm or deny that themselves. --John

4 4

Re: Sprint violations (setting space aside for slow-start allocations)
by Sean Doran 08 Oct '95

08 Oct '95

Nick - Good points. You also join the registries in making one of the two very persuasive arguments in favour of relaxing (perhaps some, perhaps all) of 206.0.0.0/8 by one bit, to allow in /19s. Slow-start is a good idea, and we have the RIPE /19 legacy to prove it. Now we need to look at whether this can be done with /18s without exhausting IPv4 too soon, as there are some real concerns about doubling the maximum number of prefixes many routers will see. I also see no problem about working out case-by-case arrangements for putting holes into our filters in the future, taking everybody's various costs into consideration. | If Sprint is not doing a good job of aggregating its announcements, | filter them, eventually they'll get around to aggregating everything | they can. There certainly is some aggregation that should be done downstream from Sprint. We try to encourage people to aggregate what they can aggregate, but some outside pressure to do so probably would help... Sean. P.S.: | So how about agreeing on pools of address space for small allocations? I think you found a good topic!

3 4

Re: filtering long prefixes
by Sean Doran 08 Oct '95

08 Oct '95

Yes, Geert Jan, but if you look at the list I prepared, you'll note that the only chunks of old style Bs that are 18-bits long all come from one home-AS and most are in a pair of old-style class Bs which easily could be aggregated into a single /15 with the loss of some routing specificity (which is lost anyway when that provider's internal metrics don't propagate to its external peers). The remainder of the 'chunks' of old style Bs are all longer than 18 bits, and most are /24s or /26s, and I see none at all that appear difficult to aggregate, or which look like anything other than leaks due to misconfiguration. If you get to the point where someone needs to have a /18 in the old-style class B space and it can't be aggregated, we can return to this. Sean.

3 2

Program: 6th Maryland Workshop on Very High Speed Networks
by Account of Maryland Center for Telecommunications Research 06 Oct '95

06 Oct '95

------------------------------------------------- 6TH MARYLAND WORKSHOP ON VERY HIGH SPEED NETWORKS ------------------------------------------------- October 30-31, 1995 (Ballroom, University Center) Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County(UMBC) ******************************************************************************* Participation with: University of Maryland Institute for Advanced Computer Studies IEEE Communication Society - Gigabit Networking Technical Committee IDA/Center for Computing Sciences Johns Hopkins University/Computer Science Department Supported by: Department of Computer Science and Electrical Engineering, UMBC IBM IOS Press MCI Sprint SUN ------------------------------------------------------------------------------- Monday, October 30, 1995 ------------------------------------------------------------------------------- 8:00-8:45 Registration and Coffee 8:45-9:00 Introduction Dr. Deepinder Sidhu Director, Maryland Center for Telecommunications Research(MCTR) Dr. Joel Morris Chair, Computer Science & Electrical Engineering, UMBC Dr. Freeman Hrabowski President, University of Maryland Baltimore County SESSION 1: -------------------------------------------------------------------- 09:00-9:45 Inder Gopal: IBM Watson Research Center (Keynote Address) Electronic Commerce: Technical Issues and Challenges 9:45-10:15 Thomas vonDeak: NASA Lewis Research Center Status of the NASA Advanced Communications Technology Satellite (ACTS) Program and B-ISDN Development 10:15-10:45 Coffee Break SESSION 2: -------------------------------------------------------------------- 10:45-11:15 Rick Wilder: MCI The NSF's very-high-speed Backbone Network Service: Architecture and Project Plans 11:15-11:45 Bob Collet: Sprint Overview of Sprint's SONET Infrastructure 11:45-12:15 J. H. Maestas: Sandia National Laboratories Experiences with SONET Transport Networks 12:15-1:30pm Lunch SESSION 3: -------------------------------------------------------------------- 1:30-2:00 Raj Jain: Ohio State University Traffic management in ATM Networks 2:00-2:30 Mani B. Srivastava, P. Agrawal, A. Asthana, M. Cravatts, E. Hyden, P. Krzyzanowski, P. Mishra, B. Narendran, and J. Trotter: AT&T SWAN: Testbed for Mobile Networked Computing 2:30-3:00 Vern Paxson: Lawrence Berkely Lab Endpoint Measurement of Network Conditions 3:00-3:30 Donald Smith: Bellcore Adaptive Congestion Controls in SS7 and Implications for Broadband Signaling 3:30-4:00 Coffee Break SESSION 4: -------------------------------------------------------------------- 4:00-4:30 J. H. Naegle: Sandia National Laboratories Progress with ATM at Sandia National Laboratories 4:30-5:00 Jonathan M. Smith: Univ of Pennsylvania TCP/IP performance of the Penn Afterburner ATM Link Adapter 5:00-5:30 Javad Boroumand: NASA Goddard Space Flight Center NASA EOSDIS Project ATM Prototyping ------------------------------------------------------------------------------- October 31, 1995 ------------------------------------------------------------------------------- SESSION 5: -------------------------------------------------------------------- 8:45-9:15 Michael Levender: Stratacom Applications Support Over ATM: An Update 9:15-9:45 Brad Makrucki: BellSouth Telecomm What's Wrong with Equivalent Bandwidth? 9:45-10:15 Roch Guerin: IBM Watson Research Center Traffic Shaping and Reshaping to Efficiently Provide End-to-End Guarantees. 10:15-10:45 Coffee Break SESSION 6: -------------------------------------------------------------------- 10:45-11:15 Magda El Zarki: Univ. of Pennsylvania Video over ATM Quality Control 11:15-11:45 Guru Parulkar: Washington University Error Control for Continuous Media Applications 11:45-12:15 Anujan Varma: University of California FAST: A Hardware Simulation Testbed for ATM Network 12:15-1:15 Lunch SESSION 7: -------------------------------------------------------------------- 1:15-1:45 Robert J. Aiken: Department of Energy/Lawrence Livermore Lab The ENERGY of HIgh Speed Networking 1:45-2:15 Ted Faber: USC/ISI Research in the ATOMIC-2 Project at ISI 2:15-2:45 Bernie Hudson: University of Ottawa High Speed Network Connecting Canada, Europe and North Africa 2:45-3:15 Jorg Liebeherr, I. F. Akyildiz and D. Sarkar: Univ. of Virginia, Virginia An Explicit Rate Control Scheme for ABR Traffic with Heterogeneous Service Requirements -------------------------------------END---------------------------------------

1 0

Welcome to nanog
by Majordomo＠merit.edu 05 Oct '95

05 Oct '95

-- Welcome to the nanog mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo" with the following command in the body of your email message: unsubscribe nanog capprove gators subscribe nanog dbarr(a)nysernet.org Here's the general information for the list you've subscribed to, in case you don't already have it: North American Network Operators Group

1 0

MCI and SprintLink are partitioned (fwd)
by Gordon Cook 05 Oct '95

05 Oct '95

Anyone willing to say what happened? ******************************************************************** Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 The COOK Report on Internet Non Profit. $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate. Site Lic $650 http://www.netaxs.com/~cook <- Subscription Info & COOK Report Index ******************************************************************** ---------- Forwarded message ---------- To: cook(a)cookreport.com Subject: MCI and SprintLink are partitioned (fwd) Forwarded message: >From spot.Colorado.EDU!westnet-site-people-request Tue Oct 3 20:48:25 1995 From: Chris Garner <cgarner(a)westnet.net> Message-Id: <199510040136.TAA06094(a)dozer.colorado.edu> Subject: MCI and SprintLink are partitioned To: westnet-site-people(a)westnet.net Date: Tue, 3 Oct 1995 19:36:50 -0600 (MDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 289 MCI and SprintLink are disconnected at the moment. MCI is having a BGP problem with SprintLink. Currently the two networks are partitioned. The problem started just after 7pm (Mountain time) and is still occuring. -- -Chris (cgarner(a)westnet.net)

8 13

Re: MCI and SprintLink are partitioned (fwd)
by Hank Nussbacher 05 Oct '95

05 Oct '95

On Wed, 4 Oct 1995 17:42:42 -0400 (EDT) you said: >> . Do all the NAPs provide online statistics? > >MAE-East & MAE-West do. Check out: > http://mfsdatanet.com/MAE/ > > --asp(a)uunet.uu.net (Andrew Partan) The best page to start from is http://www.ra.net/routing.arbiter/RA/.how.to.peer.html which has pointers to the NAP home pages for Sprint, PacBell, AADS and MAE-East and MAE-West. Another starting point is http://www.ameritech.com/NAP/othernaps.html Hank

1 0

Re: MCI and SprintLink are partitioned (fwd)
by Sean Doran 04 Oct '95

04 Oct '95

HWB - The problem is really not so much that the routing fell over but that other problems were run into, that are independent of NAPs/MAEs/etc. | . are all three (four?) NAPs really being used (I know they are | there, but despite repeated requests to at least one NAP service | provider I appear to be unable to get an answer). I do know that the | NY NAP is heavily used, including as my traffic to the Bay area | sites I need access to traverses it (modulo all the losses in | Sprintlink for at least weeks (reported to and confirmed by the | regional network that serves SDSC, though from rumors I am hearing | Sprintlink is rather not the exception, and many natives in the | community starting to get restless] SprintLink and MCI exchange traffic at two NAPs, both MAEs, and FIX-WEST. We likely will start exchanging traffic at the PAC*Bell NAP in the very near future. SprintLink and AGIS will be exchanging traffic there even before then. Others at that NAP are either in the queue wrt negotiating a bilateral agreement with Sprint, or have not yet approached Sprint with regards to a peering for various reasons. SprintLink and MCI exchange fairly heavy traffic at the Chicago NAP, very heavy traffic at the Pennsauken NAP, and extraordinarily heavy traffic at MAE-EAST, and we are have already been looking at a very strong and purely technical need to start moving traffic between ourselves directly in several other locations. The reason you see so much use of the Pennsauken NAP is that CERFNET has a DS3 ATM pipe terminated on a router there, and that is where CERFNET and SprintLink exchange a good chunk of traffic, principally because the bandwidth available to do that in New Yorsey has been greater than any other path on the west coast through which CERFNET and SprintLink could have exchanged traffic. I believe that Push could supply you with further details of CERFNET's near-future plans in this and other regards. | . Is there any evidence that the NAPs are really backing each other | up? Did someone test and document it, e.g., with a few "test" networks | in a bunch of regional networks? What are the time delays for a | switch? Does someone have consecutive traceroute outputs where a | switch among the NAPs really happened? What do you mean by backing each other up? There was never a requirement for NAPs to do that; what does fall-overs is the bilateral routing among each pair of peers at each touchdown point. BGP fallover with respect to very large changes (disconnectivity at a NAP, MAE or FIX-WEST) between two very big peers adjusts in various ways; firstly, you could have a fast IGP switching, which means convergence time within one side of a few seconds. Secondly, you could have an eBGP timeout or the like, which means convergence time in a matter of a couple of minutes or less. The key problem here is that convergence eats CPU (lots of routes to be announced or withdrawn or sent to different next-hops), and very very bad transitions can take ten to fifteen minutes, depending on the characteristics of the failures. However, fall-over happens fairly frequently and sometimes as a result of having to make code changes and the like at edge routers (routers colocated at NAPs/MAEs/FIXes etc), and we have long established that done right, it's not very painful. | . do we have some regular examples from *any* site A initiating a | connection from A to B, A to C, and A to D, where the three are | verifiably (via traceroute, I guess) would traverse different NAPs | (and hopefully only one each)? Sure; if I understand the question correctly, anybody on SprintLink or MCI should be able to do this without thinking about it. | . Are there routing stability reports accessible online from the RA | (or whoever else feels responsible for this) that graph fluctuations | at the NAPs, including correlation among them? What are the quality | metrics for routing stability? Not AFAIK. | . Do all the NAPs provide online statistics? The Sprint NAP has a statistics package which is really nifty but not yet widely publically available; you should tap Bilal or one of the other responsible people on the shoulder to show it off to you. | . Are the NAP and RA regular reports to NSF publicly (hopefully via | the Web) available? Not sure. It might be a good idea. | . Is there any way NANOG can be used to exchange status information | about networks, rather than getting comments and rumors second or | third hand. outage-request(a)sprint.net can put you on our (very widely-subscribed) list for announcing SprintLink/ICM outages, innages, root problems and potential solutions. I hope that you'll find that the quality of information there is reasonable and that volume is fairly light, and generally is what you seem to be asking for. | Even better | then posting (e.g, via some mailing list) would be an accessible | distributed data base covering all the service pproviders and | accessible via the network. Is someone already working on that? | Would not NANOG be *the* forum to cooperate on that? I'm certainly open to the idea. The first thing you'll have to realize is that when you can't get to the database because the network is broken, it can't help you... Sean.

1 0

Re: MCI and SprintLink are partitioned (fwd)
by Enke Chen 04 Oct '95

04 Oct '95

Hi, Currently MCI peers with Sprintlink at four places: Mae-East, Mae-West, New York NAP, and Chicago NAP, and these peers do backup each other. I just checked the peer status a few minutes ago. Here is what I found: interconnect up time Mae-East 6:06:45 (sheduled maintainence this morning) Mae-West 3d04 NY NAP 4d20 Chicago NAP 1w6d Clearly this data does not support the remark that a partition (total loss of peers) happened between MCI and Sprint yesterday evening. -- Enke >Anyone willing to say what happened? > >******************************************************************** >Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 >The COOK Report on Internet Non Profit. $150 >431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 >(609) 882-2572 Corporate $350 >Internet: cook(a)cookreport.com Corporate. Site Lic $650 >http://www.netaxs.com/~cook <- Subscription Info & COOK Report Index >******************************************************************** >---------- Forwarded message ---------- >To: cook(a)cookreport.com >Subject: MCI and SprintLink are partitioned (fwd) > >Forwarded message: >>From spot.Colorado.EDU!westnet-site-people-request Tue Oct 3 20:48:25 1995 >From: Chris Garner <cgarner(a)westnet.net> >Message-Id: <199510040136.TAA06094(a)dozer.colorado.edu> >Subject: MCI and SprintLink are partitioned >To: westnet-site-people(a)westnet.net >Date: Tue, 3 Oct 1995 19:36:50 -0600 (MDT) >X-Mailer: ELM [version 2.4 PL21] >Content-Type: text >Content-Length: 289 > > > MCI and SprintLink are disconnected at the moment. MCI is >having a BGP problem with SprintLink. Currently the two networks >are partitioned. The problem started just after 7pm (Mountain time) >and is still occuring. > > > -Chris (cgarner(a)westnet.net)

2 2

Re: MCI and SprintLink are partitioned (fwd)
by Curtis Villamizar 04 Oct '95

04 Oct '95

Just a random sampling: I can reach a Sprint and an MCI customer. I can also traceroute -g through Sprint and reach an MCI customer (sorry no DNS on the router, 144.228 is Sprintland and 204.70 is MCIland). Curtis traceroute to connix.com (198.69.10.2), 30 hops max, 40 byte packets 1 en-0.enss470.t3.ans.net (204.148.1.30) 2.253 ms 2.132 ms 2.049 ms 2 t0-0.cnss52.Hartford.t3.ans.net (192.103.65.9) 27.768 ms 27.648 ms 27.434 ms 3 mf-0.cnss48.Hartford.t3.ans.net (140.222.48.222) 27.838 ms 27.521 ms 27.54 ms 4 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 30.855 ms 30.531 ms 30.334 ms 5 t3-1.cnss56.Washington-DC.t3.ans.net (140.222.56.2) 36.671 ms 35.944 ms 36.505 ms 6 t3-0.enss147.t3.ans.net (140.222.147.1) 37.055 ms 36.686 ms 36.238 ms 7 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 40.192 ms 63.829 ms 213.618 ms 8 sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41) 169.323 ms 56.15 ms 216.765 ms 9 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 226.158 ms 42.494 ms 42.574 ms 10 sl-pen-1-H2/0-T3.sprintlink.net (144.228.10.34) 39.521 ms 53.347 ms 51.931 ms 11 sl-pen-7-F0/0.sprintlink.net (144.228.60.7) 46.35 ms 128.988 ms 206.026 ms 12 sl-caravela-4-s0-T1.sprintlink.net (144.228.67.110) 204.428 ms 55.455 ms 50.509 ms 13 hfd-01.rt.connix.net (204.183.68.65) 57.627 ms 57.497 ms 61.205 ms 14 mfd-hfd.pp.connix.net (204.183.69.130) 54.592 ms 52.971 ms 54.21 ms 15 connix.com (198.69.10.2) 59.009 ms 70.912 ms 68.981 ms traceroute to ns.isi.edu (128.9.128.127), 30 hops max, 40 byte packets 1 en-0.enss470.t3.ans.net (204.148.1.30) 2.273 ms 2.15 ms 2.078 ms 2 t0-0.cnss52.Hartford.t3.ans.net (192.103.65.9) 27.731 ms 27.803 ms 27.686 ms 3 mf-0.cnss48.Hartford.t3.ans.net (140.222.48.222) 28.485 ms 27.492 ms 27.525 ms 4 t3-2.cnss43.Cleveland.t3.ans.net (140.222.43.3) 42.654 ms 42.49 ms 42.396 ms 5 t3-1.cnss27.Chicago.t3.ans.net (140.222.27.3) 50.043 ms 49.993 ms 49.974 ms 6 t3-1.cnss96.Denver.t3.ans.net (140.222.96.2) 74.795 ms 74.753 ms 74.692 ms 7 t3-1.cnss8.San-Francisco.t3.ans.net (140.222.8.2) 97.726 ms 98.407 ms 98.726 ms 8 t3-0.enss144.t3.ans.net (140.222.144.1) 100.66 ms 101.765 ms 101.544 ms 9 fix-west-cpe.SanFrancisco.mci.net (192.203.230.18) 101.413 ms 101.038 ms 103.37 ms 10 borderx2-hssi2-0.SanFrancisco.mci.net (204.70.158.117) 254.546 ms 265.445 ms 214.901 ms 11 core2-fddi-1.SanFrancisco.mci.net (204.70.158.65) 153.304 ms 103.416 ms 104.602 ms 12 core-hssi-2.Bloomington.mci.net (204.70.1.41) 114.067 ms 117.875 ms 115.73 ms 13 border1-fddi-0.Bloomington.mci.net (204.70.2.130) 119.707 ms 113.654 ms 114.491 ms 14 csunet-losnettos.Bloomington.mci.net (204.70.48.6) 121.376 ms 119.585 ms 119.236 ms 15 ISI-SWRL-GW.LN.NET (204.102.78.1) 117.668 ms 118.692 ms 117.416 ms 16 ln-gw.isi.edu (128.9.16.1) 121.521 ms 118.617 ms 119.793 ms 17 cisco2-32.isi.edu (128.9.32.2) 117.898 ms 120.588 ms 120.731 ms 18 darkstar.isi.edu (128.9.128.127) 117.897 ms 120.146 ms 120.439 ms traceroute to 128.9.128.127 (128.9.128.127), 30 hops max, 12 byte packets 1 cnss32-ft2.if (140.222.32.3) 6 ms 6 ms 5 ms 2 enss218-ft0.if (140.222.218.1) 11 ms 11 ms 10 ms 3 192.157.69.9 (192.157.69.9) 12 ms 14 ms 12 ms 4 144.228.60.1 (144.228.60.1) 18 ms 125 ms 119 ms 5 144.228.10.33 (144.228.10.33) 121 ms 112 ms 100 ms 6 144.228.20.8 (144.228.20.8) 77 ms 187 ms 19 ms 7 144.228.10.42 (144.228.10.42) 204 ms 170 ms 217 ms 8 192.41.177.181 (192.41.177.181) 222 ms 143 ms 97 ms 9 204.70.74.101 (204.70.74.101) 81 ms 52 ms 102 ms 10 204.70.74.49 (204.70.74.49) 97 ms 99 ms * 11 204.70.1.129 (204.70.1.129) 284 ms 379 ms 221 ms 12 204.70.1.125 (204.70.1.125) 254 ms * 56 ms 13 204.70.1.114 (204.70.1.114) 250 ms 219 ms 258 ms 14 204.70.1.122 (204.70.1.122) 246 ms 154 ms 235 ms 15 204.70.1.34 (204.70.1.34) 265 ms 555 ms 442 ms 16 204.70.2.130 (204.70.2.130) 137 ms 287 ms 280 ms 17 204.70.48.6 (204.70.48.6) 1179 ms 135 ms 239 ms 18 * 204.102.78.1 (204.102.78.1) 312 ms 178 ms 19 128.9.16.1 (128.9.16.1) 217 ms 170 ms 234 ms 20 128.9.32.2 (128.9.32.2) 216 ms 157 ms 321 ms 21 128.9.128.127 (128.9.128.127) 198 ms 365 ms 234 ms

1 0