- Test - lists.nanog.org

Merit NOC manager position
by mak 10 Feb '92

10 Feb '92

Hi. Dale Johnson is moving to a different position at Merit, the "Network Management Systems" group manager. So this opens up the following position, FYI. Mark The University of Michigan and Merit Network, Inc. are seeking applications for the position of Network Operations Center Manager. The NOC is located at the University of Michigan, and the candidate will be employed by the University. Send applications to Tina Pryor, ITD-Resource Administration, University of Michigan, 519 W. William, Ann Arbor, MI 48109. The University of Michigan is an equal opportunity employer. Refer to the University's posting number: A-121032-TP ---------------------------------------------------------------- TITLE: Manager, Information Technology Division-Network Operations Center BASIC FUNCTION Provide management, leadership and vision in network operations for national, state, and campus networking within The University of Michigan-ITD Network Systems, including UMnet, MichNet, and the NSFNET and ANS networks. The primary focus of the Network Operations Center is hour-to-hour and day-to-day operations of the various networks, including the development and reliable execution of standard operating procedures in a 24-hour per day, 7 day per week operations environment. The Center also manages large amounts of critical configuration information, and production of routine reports on Network Performance. CHARACTERISTIC DUTIES Provide leadership and management of the Network Operations Center. Produce and guarantee reliable execution of Center responsibilities, given the resources available. Arrange for new procedures to meet the operational requirements of rapidly changing technology. Define the support needs for the Network Operations Center. Work with the Center's customers and engineering support groups to establish their operational needs. Arrange for resources to meet those needs. Respond to network and Operations Center emergencies as needed on a twenty-four hour basis. Evaluate and report on the Center's technical performance for administrative and customer audiences. Coordinate projects with other groups and managers in Network Systems and the with the Center's vendors and corporate partners. Develop staffing plans and goals, hire and train new staff, assign and prioritize projects, promote professional development and provide general functional and administrative supervision of Network Operations Center staff to meet unit objectives. Represent the Network Operations Center, Merit, and the University of Michigan on national and international committees, standards bodies, and other appropriate organizations, including providing leadership of such groups. Present the Network Operations Center, Merit, and the Networks to varied audiences via tours, lectures, and other presentations. Arrange for maintenance and physical improvements to the Network Operations Center facility. QUALIFICATIONS A Bachelor's degree in computer science, electrical engineering, applied mathematics or other related discipline. A Master's degree or an equivalent combination of education and experience is preferred. Significant knowledge and experience in the Internet and Unix environments, including knowledge and experience in managing networks using the TCP/IP protocol suite is required. Considerable knowledge of and five years experience in data networking. Three years of operations coordination experience is required, with at least two at a staff management level preferred. Ability and vision to supervise the design and coordination of large scale, complex projects, establish goals, and meet objectives is required. Ability to communicate well with technical and administrative people, and work cooperatively with staff, peer managers and upper management is required. Ability to delegate responsibility and be accessible to technical staff is required. Active participation in networking organizations at a national level is desirable. Three or more years of computer programming experience is desirable. Commitment to quality operations and a vision of the future is required.

1 0

Additions to the NSFNET policy-based routing database
by Belinda Sue Blair 07 Feb '92

07 Feb '92

The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 192.146.147 DGSD 195 Digital Sound Corporation, 6307 Carpinteria Ave., Carpinteria, CA 93013, USA 192.146.101 LEXMARK-DMZ 750 756 Lexmark International Inc., 740 New Circle Road, Northwest, Lexington, KY 40511, USA 192.138.207 CRIC-NET 560 281 Collaborative Research Incorporated, 1365 Main Street, Waltham, MA 02154, USA 192.138.179 NEMC-NET3 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.178 NEMC-NET2 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.177 NEMC-NET1 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.168 UTEXAS-MSI 281 114 University of Texas at Austin, Marine Science Institute at Port Aransas, 750 Channel View Drive, Port Aransas, TX 78373, USA 192.138.161 STEDWARDS 280 114 St. Edwards University, 3001 S. Congress Ave., Austin, TX 78704, USA 192.136.128 LABCOM-IG 184 164 US Army Laboratory Command, US Army LABCOM, 2800 Powder Mill Rd., Adelphi, MD 20772, USA 192.136.127 WSMR-NET13 164 184 USAISC-TWS-V, Commander, USAISC-WS, White Sands Missle Range, NM 88002, USA 192.136.126 WSMR-NET12 164 184 US Army Atmospheric Sciences Lab, Commander/Director, US Army Atmospheric Sciences Lab, SLCAS-D, WSMR, NM 88002, USA 192.136.125 WSMR-NET11 164 184 USAISC-TWS-V, Commander, USAISC-WS, White Sands Missle Range, NM 88002, USA 192.136.124 MCPH-NET4 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.123 MCPH-NET3 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.122 MCPH-NET2 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.121 MCPH-NET1 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 134.184 VUB-ULB 590 Vrije Universiteit Brussel + Universite Libre de Bruxelles, Rekencentrum; Pleinlaan 2; B-1050 Brussels, BELGIUM 132.209 UQTR-IP-NET 603 601 Universite du Quebec a Trois-Rivieres, 3351 Boulevarde Des Forges, Quebec G9A 5H7, CANADA 192.135.195 NT02 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 192.135.194 NT01 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 192.82.158 VMU-NET 590 Veterinaermedizinische Universitaet Wien, EDV-Zentrum; Linke Bahngasse 11; A-1030 Wien, AUSTRIA 192.71.193 UHA-LAN 1238 701 University Council (UHA), UHA, Box 45501, S-104 30 Stockholm, SWEDEN 192.31.114 DRINET 200 201 Novell, Inc., 2180 Fortune Drive, San Jose, CA 95131, USA 157.238 SESQUI-2 114 280 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251, USA 156.106 ITU-GVA-1 590 1238 International Telecommunications Union, Place de Nations, CH-1211 Geneva 20, SWITZERLAND 156.26 SHOCKNET 93 Wichita State University, 1845 Fairmount, Wichita, KS 67208-1595, USA 192.112.84 AGSIMNET 210 209 American Graduate School of International Management, 15249 North 59th Avenue, Glendale, AZ 85306, USA 192.109.58 FRIEDE 701 1238 Friede Beratungsgesellschaft mbH, Westendstr. 117, D-W-8000 Muenchen 2, GERMANY 192.109.31 EMBNET-HH 293 291 n/a, GERMANY 192.92.69 INFOLAN 174 Infonet, Inc., 2100 E. Grand Avenue, M/S B237, P.O. Box 1022, El Segundo, CA 90245, USA 192.135.215 NTBNR 114 280 Northern Telecom/Bell Northern Research, 2201 Lakeside, Richardson, TX 75081, USA 192.135.196 NT03 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 155.222 RIA-6-NET 164 184 USAISC-AMCCOM, Attn: ASQNC-ARI-IOC-N, Rock Island Arsenal, Rock Island, IL 61299-7210, USA 152.88 DDETH 590 1238 EMA-EAWAG, Ueberlandstrasse 129/133, CH-8600 Duebendorf, SWITZERLAND 147.191 USWSIS 209 210 US West Inc., 9785 Maroon Circle #160, Englewood, CO 80112, USA 144.197 LADC 174 750 Lockheed Advanced Development Company, P.O. Box 250, Plant B6 Building 311, Sunland, CA 91041-3702, USA 142.76 SUNNYBROOK 601 602 Sunnybrook Health Science Centre, Rm S-131, 2075 Bayview Ave., North York, Ontario M4N 3M5, CANADA 141.61 MPIB-NET 293 291 Max-Planck-Institut fuer Biochemie , Rechenzentrum Am Klopferspitz D-W- 8033 Martinsried, GERMANY 192.88.203 PGWKS 701 279 PageWorks, 36 John F. Kennedy Street, Cambridge, MA 02138, USA 192.86.8 MUSE-ETHER2 200 754 MicroUnity Systems Engineering, Incorporated, 4699 Old Ironsides, Suite 410, Santa Clara, CA 95054, USA 192.84.1 BBN-SYSENGRC1 1384 1383 BBN Communications, 150 Cambridge Park Drive, Cambridge, MA 02140, USA 192.136.41 TREVANO 590 1238 Scuola Tecnica Superiore, CH-6952 Canobbio, SWITZERLAND Total NSFNET T1 announced networks: 4601 T3 Network: Network IP: 192.31.114 Network Name: DRINET Location: Novell, Inc., 2180 Fortune Drive, San Jose, CA 95131, USA Country Code: US 1:200 BARRNet 2:201 BARRNet Network IP: 192.84.1 Network Name: BBN-SYSENGRC1 Location: BBN Communications, 150 Cambridge Park Drive, Cambridge, MA 02140, USA Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Network IP: 192.86.8 Network Name: MUSE-ETHER2 Location: MicroUnity Systems Engineering, Incorporated, 4699 Old Ironsides, Suite 410, Santa Clara, CA 95054, USA Country Code: US 1:200 BARRNet Network IP: 192.88.203 Network Name: PGWKS Location: PageWorks, 36 John F. Kennedy Street, Cambridge, MA 02138, USA Country Code: US 42:702 Alternet Router Network IP: 192.108.246 Network Name: ARD-NET Location: Federal Bureau of Investigation, 10th & Pennsylvania Ave., Washington D.C. 20535, USA Country Code: US 42:702 Alternet Router Network IP: 192.138.177 Network Name: NEMC-NET1 Location: Tufts University, 169 Holland Street, Somerville, MA 02144, USA Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Network IP: 192.146.101 Network Name: LEXMARK-DMZ Location: Lexmark International Inc., 740 New Circle Road, Northwest, Lexington, KY 40511, USA Country Code: US 1:1751 Lexmark, Lexington, KY Total NSFNET T3 announced networks: 1174 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin(a)merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. ************** -B. Sue Blair Merit Network Operations

1 0

CERT Advisory - Michelangelo PC Virus Warning
by CERT Advisory 06 Feb '92

06 Feb '92

=========================================================================== CA-92:02 CERT Advisory February 6, 1992 Michelangelo PC Virus Warning --------------------------------------------------------------------------- The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information concerning a personal computer virus known as Michelangelo. The virus affects IBM PCs and compatibles. A description of the virus, along with suggested countermeasures, is presented below. --------------------------------------------------------------------------- I. Description The Michelangelo virus is a computer virus that affects PCs running MS-DOS (and PC-DOS, DR-DOS, etc.) versions 2.xx and higher. Note, however, that although the virus can only execute on PCs running these versions of DOS, it can infect and damage PC hard disks containing other PC operating systems including UNIX, OS/2, and Novell. Thus, booting an infected DOS floppy disk on a PC that has, for example, UNIX on the hard disk would infect the hard disk and would probably prevent the UNIX disk from booting. The virus infects floppy disk boot sectors and hard disk master boot records (MBRs). When the user boots from an infected floppy disk, the virus installs itself in memory and infects the partition table of the first hard disk (if found). Once the virus is installed, it will infect any floppy disk that the user accesses. Some possible, though not conclusive, symptoms of the Michelangelo virus include a reduction in free/total memory by 2048 bytes, and some floppy disks that become unusable or display "odd" graphic characters during "DIR" commands. Additionally, integrity management products should report that the MBR has been altered. Note that the Michelangelo virus does not display any messages on the PC screen at any time. II. Impact The Michelangelo virus triggers on any March 6. On that date, the virus overwrites critical system data, including boot and file allocation table (FAT) records, on the boot disk (floppy or hard), rendering the disk unusable. Recovering user data from a disk damaged by the Michelangelo virus will be very difficult. III. Solution Many versions of anti-virus software released after approximately October 1991 will detect and/or remove the Michelangelo virus. This includes numerous commercial, shareware, and freeware software packages. Since this virus was first detected around the middle of 1991 (after March 6, 1991), it is crucial to use current versions of these products, particularly those products that search systems for known viruses. The CERT/CC has not formally reviewed, evaluated, or endorsed any of the anti-virus products. While some older anti-virus products may detect this virus, the CERT/CC strongly suggests that sites verify with their anti-virus product vendors that their product will detect and eradicate the Michelangelo virus. The CERT/CC advises that all sites test for the presence of this virus before March 6, which is the trigger date. If an infection is discovered, it is essential that the user examine all floppy disks that may have come in contact with an infected machine. As always, the CERT/CC strongly urges all sites to maintain good backup procedures. --------------------------------------------------------------------------- The CERT/CC wishes to thank for their assistance: Mr. Christoph Fischer of the Micro-BIT Virus Center (Germany), Dr. Klaus Brunnstein of the Virus Test Center (Germany), Mr. A. Padgett Peterson, P.E., of the Technical Computing Center at Martin-Marietta Corp., and Mr. Steve R. White of IBM's Thomas J. Watson Research Center. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams). Internet E-mail: cert(a)cert.sei.cmu.edu Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.sei.cmu.edu (192.88.209.5).

1 0

The CIX and the NSFNET regionals - a dilemma
by Vince Fuller 05 Feb '92

05 Feb '92

As some of you are probably aware, BARRNet is in the process of establishing a connection to the CIX. While working out the details of how routing will work between BARRNet member sites and customers/members of other CIX-connected networks, I have run into some difficulty which may indicate a fundamental problem for use of the CIX to interconnect research-oriented networks. In short, I believe that such networks face a serious dilemma if they connect to the CIX: how to provide unrestricted commercial-to-commercial access to the CIX-reachable networks while at the same time providing optimal routing over high-bandwidth NSFNET paths for research-oriented traffic. All, of course, while not creating large amounts of management overhead or strange routing anomalies. I would very much appreciate feedback from this community on the enclosed message, which I originally sent to the CIX tech group. Of particular interest to me is whether this group considers the assymetric routing which would be engineered by my proposed "solution" to this dilemma to be an issue and whether or not the "solution" would adequately address any NSFNET AUP concerns (I use the world "solution" loosely as I am neither proud nor very pleased with the described scheme). Thanks, Vince Fuller/BARRNet --------------- As you are probably aware, BARRNet is in the process of establishing a connection to CIX-WEST in Santa Clara. At this time, pretty much all of the administrative details of doing so have been finalized. While thinking about how routing will work, however, it occurred to me that there are some major technical details which remain unresolved. In particular, how are we to deal with routing between research-oriented networks which should use the T3 NSFNET but which will use the CIX due to the way routing is set up (as I understand it, current CIX members prefer all CIX-advertised routes over those which they may learn via the NSFNET, either by weighting advertisements or simply by only using the NSFNET as a default path). This will be a problem (politically severe immediately, technically eventually) for certain paths, such as for BARRNet sites which wish to access the San Diego Supercomputer center (and I assure you that there are several universities attached to BARRNet which have high bandwidth requirements for this particular case), and will become more severe as the T3 NSFNET becomes fully deployed. To solve this problem, it is necessary to determine whether a given network conversation is affectted by the NSFNET AUP or not. Since conformance to the AUP is based on the content of the conversation, it is not possible for the routing system to do this in an automated way - the best approximation we can make is to divide the world into those networks which are unaffected by the AUP (I'll call them "research" sites) and those which are. Routing via the NSFNET would then be preferred for all traffic which inolves a "research" site and via the CIX for all else. Unfortunately, I don't believe such a routing plan is implementable using current technology, as it requires that routing decisions be based on both traffic source and destination. The best that could be done would be to bias routing such that the each CIX-connected midlevel prefers any NSFNET path it has to "research" sites over the CIX path. This could be done in two ways: 1. Configure each CIX-connected mid-level to suppress advertisement of "research" sites to the CIX, guarenteeing that those networks are only reachable via the NSFNET. 2. At each CIX-connected mid-level, adjust metrics such that advertisements for other mid-levels' "research" networks are preferred via the NSFNET. Either "solution" creates a number of problems: 1. Routing must be coordinated among the CIX-connected mid-level networks to establish which networks are "research". Not a technical problem, but procedurally a pain in the neck. 2. Both are unwieldy in that each CIX-connected midlevel will need to maintain a list of all of "research" sites, either within its own network (solution #1, painful) or from all other CIX-connected midlevels (solution #2, more painful) 3. Both engineer route assymetry into the system. This is ugly and may or may not be acceptable. To expand on point #3, here are examples involving real sites, one "research" (Berkeley) and one "commercial" (InterOP) site in BARRNet and one "research" (ISI) and one "commercial" (Hughes Aircraft) site in CERFNet/Los Nettos (I picked these out of a hat, so to speak; I have no idea how much actual traffic flows among these four). In order to allow the NSFNET path to be used for the "research" sites, both CERFNet and BARRNet will need to hack their routing configurations to prefer the NSFNET path for Berkeley and ISI. This generates symmetric and "appropriate" paths for two of the possible communication pairs: Berkeley<->ISI and InterOP<->Hughes, but codifies assymetry for the mixed "commercial" and "research" pairs. For Interop<->ISI, BARRNet will route to ISI via the NSFNET but CERFNet will route back to InterOP via the CIX. In the Berkeley<->Hughes case, BARRNet will use the CIX to route to Hughes but CERFNet will route back to Berkeley via the NSFNET. Not pretty. There is also another policy problem with the presence of the NSFNET and it's AUP - even if all CIX-connected organizations are configured to prefer routing via the CIX for "commercial" networks, what happens if the path between two "commercial" networks via the CIX fails? If the networks are also advertised via the NSFNET, suddenly what was an unrestricted path between the two is now subject to the NSFNET AUP, without the knowledge of any user. It seems to me that the only way to prevent this is to never advertise to the NSFNET those networks which may wish to transmit any non-AUP traffic. Have these problems been previously addressed by the CIX membership? Are there solutions which I am missing? Does no one else consider these issues to be a problematic? When I explained this to my management, there was very serious concern voiced, in particular over the use of the non-T3 path for AUP-conformant sites (i.e. between BARRNET members and SDSC), since traffic between purely research-oriented sites (such as universities) should use the network which has been expressly provided for it - the T3 NSFNET. Your comments and thoughts on this matter would be greatly appreciated.

3 2

The CIX and the NSFNET regionals - a dilemma
by brian＠lloyd.com 05 Feb '92

05 Feb '92

> From: Martin Lee Schoffstall <schoff(a)psi.com> > Subject: Re: The CIX and the NSFNET regionals - a dilemma > Date: Tue, 04 Feb 92 22:47:42 -0500 > > > I've deferred responding publicly to the com-priv message since I hoped > others would. But I will respond to this.... > > there isn't a routing "problem". there are gigapackets/month running > through the CIX reliably, with little latency, and very inexpensively. > > What vaf wants is some tuning for the high bandwidth path that he and > a very few others have by the grace of nsf and tax $'s. it is a > reasonable request given that people don't want to ante up quite yet > for t3 cix interconnects. This tuning to my knowledge is driven > by a fairly small % of the total CIX networks (10 out of 500?). Right now the performance of the NSFnet is pretty bad (even the T3 network performance is worse than a CIX provided connection) so you are probably doing your customers a service by using the CIX to route packets instead of the NSFnet. But let's look into the future where ANS finally gets its technical act together and the T3 NSFnet really starts to hum. Add in much greater use of the CIX and I can see an inverted picture where the CIX is more of a bottleneck than the NSFnet. Let me bring this closer to home for you. The federal government is paying to provide a T3 network for research and education. I suspect that NYSERnet is intended to be a beneficiary of this service. I also presume that PSI is still the carrier for NYSERnet (please correct me if I am wrong). In that case, by running traffic through the CIX you are circumventing a federal resource. Not a problem now but what if the NSFnet gets its act together? In that case you, PSI, will be doing your clients who may legitimately use the NSFnet, a GREAT disservice. Were I them I would become POWERFULLY annoyed. How are you going to deal with the problem then? Bottom line here Marty is that you and every other service provider who carries both CO and RE traffic had better have a DAMNED good answer to this problem. I would recommend you begin to think about it NOW. I have been harping about dropping AUPs on the NSFnet but that is unlikely to ever happen so we are going to have to live with the detritus. Now one last item: don't get on Vince's case. He has been tasked with solving a problem and he is doing his best. He has identified a problem that clearly ought to be dropped in your lap (collective "your" because I suspect that CERFNet and possibly UUnet/Alternet are in the same boat). Perhaps you ought to say "thank you" and work with him instead of pooh-poohing his posting. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian(a)lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392

2 1

Re: The CIX and the NSFNET regionals - a dilemma
by Martin Lee Schoffstall 05 Feb '92

05 Feb '92

John, Could you elaborate on your technical criteria for this? For instance is it 10Mbps - 45Mbps pipe access? 4Mbps spikes? what? Are these commercial or academic organizations? Marty PS: I note that your NSFNet T3 has a 10Mbps ethernet interface as of 2 weeks ago, do things change if/when it goes to FDDI? -------- > From: Martin Lee Schoffstall <schoff(a)psi.com> > Subject: Re: The CIX and the NSFNET regionals - a dilemma > Date: Tue, 04 Feb 92 22:47:42 -0500 > > > I've deferred responding publicly to the com-priv message since I hoped > others would. But I will respond to this.... > > there isn't a routing "problem". there are gigapackets/month running > through the CIX reliably, with little latency, and very inexpensively. > > What vaf wants is some tuning for the high bandwidth path that he and > a very few others have by the grace of nsf and tax $'s. it is a > reasonable request given that people don't want to ante up quite yet > for t3 cix interconnects. This tuning to my knowledge is driven > by a fairly small % of the total CIX networks (10 out of 500?). I am providing the following data based on NEARnet's current membership in order to put the situation in perspective. I would expect that the ratios would vary significantly from one network service provider to another. Of NEARnet's 115 members, we would require such "tuning" (as mentioned above) for at least 20 organizations. This represents 60-70 network routes out of about 250. This considers only bandwidth; certainly reliability and latency might also force transit network selection. The routing issue is very real for any network which serves the academic and research community. Providing for their needs, while preventing the Internet from segmenting, is the significant challenge before us. /John

1 0

Re: The CIX and the NSFNET regionals - a dilemma
by Joe Ragland 05 Feb '92

05 Feb '92

One additional comment... Aside from CIX/NSFNET routing problems, we have seen some of the consequences of multiple backbones with the current T1 and T3 NSFNET backbones and the interconnect between the two. That's how we find routes from the East Coast to the West Coast and back again, especially when the active interconnect is at SDSC. The routing arbitrator in this case is the same as the operator of both backbones but that doesn't help since the problems are fundamental to basic routing design. --joe

3 2

Re: The CIX and the NSFNET regionals - a dilemma
by John Curran 05 Feb '92

05 Feb '92

-------- Vince, I recently wrote a breif message on this same topic which mentions some possible solutions (none good). I attached it here to help clarify the issues involved for those network service providers which have a major research component. /John ----------- Date: Mon, 27 Jan 92 22:22:13 EST From: John Curran <jcurran(a)nic.near.net> To: Folks:; Subject: NSFNET and CIX routing issues Hello All, John Rugo passed along the message regarding the various routing issues that arise for a regional that connects to both the CIX and the NSFNET. I would like to summarize the situation that occurs to insure that we are all working on the same problem. We welcome any and all thoughts on this issue. Given that a basically research and educational network (such as NEARnet) has a high-speed connection (assume 10 or 45 Mb/s) to the NSFNET and also connects to CIX to exchange commercial traffic, here are the ramifications: Any network which is only CIX-reachable presents no problems. You accept the route for the site and send any traffic via the CIX. Routes to all of NEARnet's members are made available to that site and their network sends traffic for NEARnet members via the CIX. Any network which is NSF AUP compliant and prefers to use the NSFNET is not a problem: You insure that such network routes are not announced via the CIX and NEARnet members will automatically use the NSFNET to reach them. Likewise, NEARnet will not announce routes to these "R&E" networks via CIX, which prevents any return traffic from taking the wrong path. Note that both of the above policies work, but cannot be simultaneously implemented in almost any network today. The policies would require that routes back to an R&E site (say, "Harvard") be sent to the CIX so that a purely commercial site (say, "TRW") can access them, yet it also requires that the route to Harvard not be announced in order that any other CIX- reachable R&E site (say, "Stanford") does not utilize the slower path. This is only a problem if: - There exists R&E members that utilize more peak bandwidth than the CIX path will allow. (There is: Harvard Astrophysics, MIT Laboratory for Computer Science, BBN packet video, etc..) - The routes that are used by R&E sites is the same as the routes used by your non-R&E sites. (They are: packets are generally routed based on destination, and not on any history such as "color" or source network) - There exists both R&E and non-R&E traffic on the network (There will be; or there is no reason to pursue the CIX). How technology can solve the problem: If you can separate your network into two distinct networks with separate routers for R&E and non-R&E members, then you can maintain distinct routing tables for each type of member. This is not pretty, or cost effective. If you place a box at your border which not only routes on destination but also on the source of the packet, then you can effectively maintain distinct routing tables for R&E and non-R&E sites. This does create a traffic bottleneck and single point of failure. If you mark packets with a indication of whether they are commercial or R&E, and then build a router which understands the indication, then you can route each packet accordingly (and also solve the mixed-R&E case nicely.) That's the situation to the best of my knowledge. If anyone sees a solution, or has questions about the assumptions, I'd be interested in hearing from you. /John ------- End of Forwarded Message

1 0

Re: The CIX and the NSFNET regionals - a dilemma
by Joe Ragland 05 Feb '92

05 Feb '92

Vince's problems with CIX vs. T3 NSFNET routing reminded me of a recent posting to the com-priv list from Dennis Ferguson. I hope Dennis doesn't mind my forwarding his concerns to these groups also. There's much in common here. --joe

1 0

Re: The CIX and the NSFNET regionals - a dilemma
by Dennis Ferguson 05 Feb '92

05 Feb '92

John, > How technology can solve the problem: [...] > If you mark packets with a indication of whether they are commercial or > R&E, and then build a router which understands the indication, then you can > route each packet accordingly (and also solve the mixed-R&E case nicely.) I'd point out (probably unnecessarily) that if you replaced "commercial" and "R&E" with "wants maximum reliability" and "wants maximum throughput" it would immediately conjure up a way to maintain a split routing table, with type-of-service. While no current routers support this, there are at least bits in the IP header to be used for this, and OSPF could carry the routes and get the dual routing tables right if someone actually bothered to implement that part of the protocol. Now, if you had routers which had a knob which said "for any packet which arrives though this interface with the default TOS, change the TOS to one of commercial or R&E", in this way allowing you to classify packets as "AUP-compliant" or "commercial" when they entered your network, you could effectively do what was suggested above, all with existing but seldom-implemented bits of the protocol. It also might allow users to pick their own preferred routing by setting the TOS bits on their own. This isn't perfect. It isn't quite clear to me how one would assemble the dual routing tables, picking the outbound direction properly for networks which can only be routed one way while splitting, networks with alternative routing, without importing all routes from everywhere. Despite this, however, it seems like about the quickest way to obtain source-based policy routing in cases where only a limited number of policies (like two) exist, since most of the protocol knobs exist already. Dennis Ferguson

1 0