- Test - lists.nanog.org

None
by Lucia Cerbai 10 Oct '95

10 Oct '95

subscribe l.cerbai(a)iunet.it

1 0

Re: Funding for NAPs...
by sincos＠bellcore.com 09 Oct '95

09 Oct '95

Just to confirm, what Gordon said about the Bellcore/AADS/PB funding arrangement is true. AADS and PB do not receive any money from NSF for NAPs. Bellcore receives a small amount for coordinating the project, and for some network management research. Does the $2K (per month?) for connecting to the MFS NAP/MAE include access costs, or just the colocation charge? Dave

3 2

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