Summary of NSFNET Regional-Techs Meeting, January 21-22, 1993 in Boulder, Colorado Merit sponsored a meeting of the NSFNET Regional-Techs in Boulder, Colorado during January 21-22, 1993. The meeting was generously hosted by Roy Perry of US West. FARNET met simultaneously in Denver. The attendance list for the meeting is appended. Most of the regionals and midlevels were represented, along with commercial network service providers, router vendors, government agency network providers and NSF. The purpose of this meeting was to allow the regional-techs to get together and have a focused discussion about networking plans. The Internet is evolving and direct action by the network operators and router vendors needs to take place in the near term (6-8 months) in order to provide a network architecture that allows for expected growth rates. Last November, The Internet Engineering Task Force discussions indicated that the NSFNET Backbone Service and regional networks move quickly to implementing an architecture called "Classless Inter-Domain Routing" (CIDR). This architecture suggests changes to the nature of the routing protocols and interactions between routing domains (eg. each regional is its own routing doman). The changes include moving to a new version of the Border Gateway Protocol which supports the grouping or aggregation of routing information when it is stored in routers and conveyed as protocol information between routing domains. The Merit staff nominated a person to lead each session covering the agenda items listed below, and "packed" the audience with friendly experts on the respective topics. Topics Covered in the Meeting 1.) GIX, NAPs, Route Servers Elise Gerich (Merit), discussion leader The NAP concept is not totally new. Any time you have multiple organizations homed on a shared medium, it might be considered a NAP. As more and more organizations interconnect it has become more necessary to better plan these interconnections and therefore, several pilots have emerged to test the functions needed at a NAP. Alternet, PSI, and Sprint initiated the MAE-East experiment which could be considered a distributed NAP. RIPE and Merit have both experimented with the concept of a route server. The purpose of the session was to discover what the regional technical representatives felt a route server should do and how it would compliment the system. Notes from Elise's talk: Introduction: What is a route server? How does it play in the NAP? How to test if it works? Goals: Maximal Connectivity Stable, Consistent Routing Manageable Routing NAPS: immature NAPs eg. cornell implementation (not planned) adolesent NAPs eg. fix-east (planned) coming of age of NAPs - mae-east RS design goals 2 proposed models: 1. single RS with world wide routing information or: 2. multiple RSs each with Regional (continental) routing information Ripe is doing #2, MERIT is working on #1. General feeling was that a merged form might be best, use the DNS model. The RS is actually two part, a policy engine and a route engine. GIX: looks & smells like a NAP, doesn't taste like one. has a worldwide flavor Questions: scope of policy - management visability move lvl2 to national cloud need route&policy filters where is the policy description language? need to distribute for disaster recovery. timing concerns. how to communicate changes to remote RS 2.) Implementation of CIDR and Supernetting Vince Fuller (BARRnet), discussion leader CIDR is billed as a short term solution, and to get started there are immediate operational actions needed. To quote V. Fuller, J. Yu, T. Li and K. Varadhan in RFC 1338, what is needed are "strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers." The discussion included: how to phase in route aggregation, how to configure routing policy for aggregation, how aggregation will be used, test plans for the BGP-4 protocol, and the requirement for network renumbering. Jeff Honig of the Cornell "gated" group led a discussion about changes to the gateway daemon in support of CIDR. This was important since the ANS backbone will be using the gated program for its routing support. Notable results of discussion at this session included agreements that the regionals should cooperate to implement CIDR in multiple phases, with BGP-4 and route aggregation to be targeted for June, 1993. An Internet Draft should be written on deployment of CIDR in the NSFNET backbone and the regional networks. Configuration options will allow the backbone to accept route aggregates from regional networks, and then announce those aggregates to other regionals and midlevels. Vince's slides: Thoughts on CIDR in the NSFNET Regionals Address assignments in preparation for CIDR Obtaining a block of class-Cs from the NIC Assignment within the regional Multiply-connected regionals Backbone/regional responsibilities for aggregation policy Who maintains the policy configuration? Which peer implements aggregation? Configuring NSFNET to support aggregation How should routing policy be specified and conveyed between regionals and Merit/NSFNET? How should the current routing configuration process be modified to support aggregation configuration? what will gated support (Jeff H.) How should inter-domain routing protocols (ie. EGP BGP 1-3, BGP 4, and later IDRP) be used in the CIDR environment? ("CIDR, default, or die") IGP considerations - VLSM + Class A/B/C Impact of CIDR on mixed-use net (i.e. AUP) Multiple Supernet blocks for policies? 3.) Address allocation strategies with CIDR Dan Long (NEARnet), discussion leader This session covered the address administration aspects of CIDR. Regionals should be prepared to handle configuration of address blocks, and to do this there should be good communication between the network operators and those handing out the network numbers. The Regional-techs discussed methods of obtaining, handling and assigning network numbers to their members from blocks obtained from the NIC. Regionals and midlevels are advised to utilize CIDR address allocation in order to conserve routing table space in the Internet. Dan's slides: Dan Long Class C Allocation Rules Organizations should get contiguous blocks of C's based on the number of hosts: Hosts C's <256 1 <512 2 <1024 4 <2048 8 <4096 16 (<8192 32) upon request Organization should get contiguous blocks of C's based on the number of subnets: >1 C per subnet to max of 32 Subnetting C's is not required but is permitted, of course. ------------------------------------------------------------------------ Address Allocation Strategies with CIDR Goals: (Conflicting) Limit use of B:s Maximize aggregation (CIDR/Supernetting) Limit explosion of C's before CIDR is ready Don't break Lans or Land admins -------------------------------------------------------------------------- Status of A's 77 unassigned -64 Reserved -13 available IANA only Status of B's *9000 unassigned IANA says IR may allocate small blocks to regional (e.g. NIC) registries ------------------------------------------------------------------------ Status of C's *2,053,000 unassigned - 1,048,000 reserved - 1,005,000 available split into 8 blocks: 192 + 193 Pre-existing 194 + 195 Europe 196 + 197 Others 198 + 199 North America 200 + 201 Central + South America 202 + 203 Pacific Rim 204 + 205 Other 206 + 207 Other n-year blocks allocated to providers for customer use ------------------------------------------------------------------------ Class B Allocation Rules organizations with > 32 subnets or organizations with > 4096 hosts or organizations with a bridged LAN with stupid hosts 1. 1-->2 (ARP) 2. 2-->1 (via 3) ------------------------------------------------------------------------ Examples Company with 25 subnets Conglomerate with 35 subsidiaries and 100 LANs per subsidiary State with 400 K-12 school districts with 10 schools per district + 2 LANs per school Others? Questions Where's the best dividing line between B's + C's? Now? Later? How do regional registries + NSP's decide which addresses to assign out of a block of C's? Others? 4.) Transition to "Next Generation NSFNET" Dan Jordt (NorthWestNet), discussion leader Major transitions of internet operations need quite a lot of planning in order to happen smoothly. If nothing else, Merit has learned this over the last few years:-). Though it is too soon to know who the new players will be for the NSFNET vBNS, RA and NAP providers, enough is known to project some of the potential problem areas, forecast changes that may occur as a result of the new architecture, and suggest some preparations that can be made in advance. During this meeting, Peter Ford of the NSF Network Engineering Group presented an overview of NSF's latest thoughts about the upcoming solicitation for the follow-on NSFNET architecture. Dan Jordt Transition to the Next Generation NSFNET by Dan Jordt Director, Technical Services NorthWestNet MERIT's Annual Regional Techs Meeting Boulder, Colorado Thursday, January 21, 1993 -------------------------------------------------------------------------- Transition to the Next Generation NSFNET Review of NSF's Public Draft Program Solicitation Review of FARNET's Report What we know about the final solicitation What can we (the regionals techs) do to prepare for the transition Discussion ------------------------------------------------------------------------------ Review of NSF's Public Draft Program solicitation Division of Responsibilities Very high speed Backbone Network Services provider (vBNS) Network Access {point (NAP) manager Routing Authority (RA) Two separate awards (NAP?RA and vBNS) Funding: approximately $10M per year Timing: 5 year cooperative agreements to commence April 1994 ---------------------------------------------------------------------------- Very High Speed Backbone Network Services Provider (vBNS) must: Connect NAPs at 155 Mbps or better Switch both IP and CLNP Implement both BGP and IDRP Support multicasting and video teleconferencing Establish quality service metrics for network performance evaluation Establish Procedures to work with NAP/RA and other network personnel to resolve problems Participate in development of advanced routing technologies (e.g. TOS routing) ---------------------------------------------------------------------------- Network Access points (NAPs) manager and routing Authority "A NAP is defined as a high speed network or switch to which a number of router can be connected for the purpose of traffic exchange and interoperation" The NAP Manager?RA must : Establish and maintain 100 Mbps (or better) LANs or MANs as AUP-Free NAPs Develop attachment policies, procedures, and fee schedules for connecting to NAPs Specify and ensure reliability and security standards Establish and maintain a Route Server supporting both IDRP and BGP, and switching both CLNP and IP Ensure routing stability and provide for simplified routing strategies (e.f. default routing) Establish procedures to work with vBNS Provider and other network personnel to resolve problems -------------------------------------------------------------------------- Networks attaching to a NAP must: Connect at T1 or better Switch both IP{ and CLNP Support both BGP and IDRP Support Video Teleconferencing Pay pro-rated cost of maintaining NAP and RA Subscribe to policies set by the RA The Federation of American Research Networks (FARNET) Report on the NAP Manager/RA and vBNS Provider Draft Solicitation
From the FARNET report:
"The transition from the current architecture to the new one will be extremely complex. A comprehensive transition plan must be developed and managed to protect stability, and existing providers must be represented in the planning process." Consensus opinions and Recommendations 12. NSF should place the new solicitation more clearly within the NREN context. 2. The plans for governance and management of the new infrastructure, and the process for achieving them, should be stronger and more explicit. 3. Transition planning must begin early and must include the provider community the organizations and institutions that furnish network services today. 4. Separate the Routing Arbiter function from that of the NAP Manager. 5. Enforcement of "appropriate use: policies will continue to be an issue under the new plan. 6. NSF's leadership role in extending networking to all of research and education should be reaffirmed and continued. 7. Criteria for attachment to NAPs and to the vBNS are critical and should be described by NSF in the solicitation. ---------------------------------------------------------------------------- The FARNET Report (cont.) 8. We recommend the following priorities in setting evaluation criteria for the review of responses to the final solicitation. GOAL Priority Promotion of broad infrastructure Very High Interaction with community, including Very High technology transfe Continuity and stability of services High QOS* measurement, accountability High Advancement of technology High/Medium Commercialization Medium Cost-effectiveness Medium CLNP availability Medium Facilitation of new applications Medium Provision of video services Low/Medium 9. NAP parameters should be based on multiple dimensions and should not be set solely on the basis of cost, which is only one component of the total NSFNET system. 10. We strongly recommend that the following technical requirement be included in the solicitation. The vBNS should provide redundancy among NAPs using proven technology. NSF should require connecting current T3 network to NAPs as part of the transition. The vBNS provider should carry full routing information (given the limitations of route server technology). The vBNS provider should have a publicly available MIB. ---------------------------------------------------------------------------- What we know about the current solicitation. Final version of solicitation made public by late Feb 93 Proposals due 75 days later Four supercomputer sites to be connected by vBNS Some number of NAPs (<<20) to be connected to vBNS Expect new language to firm up a few items from the draft solicitation, but intent is not to prescribe solutions Instead, NSF left requirements general enough to incent creative responses. Upside: NSF gets wide variety of responses, maximizing probability of technology and policy breakthroughs. Downside: Planners (technical and policy) must evolve within the structure prescribed by the award Timing becomes an issue. -------------------------------------------------------------------------- Timeline Comparisons NIS Solicitation T1 to T3 transition Transition to next NSFNET (estimates) * Jan 91 - Test T3 network * * deployed * * * * April 91 -T3 carries 1st * *'production' level traffic * * * * * * * * * Feb 93 - solicitation * * made public * * * * * * May 93-proposals due * * June 93-review panel * * July 93-NSB approval May 92-proposals due * * * April 92-T3 carries 1/2 of* Sept 92-award made * all NSFNet traffic * public * * Nov 93-prototype * * deployed * * * * Jan 94-First production * * * * Jan 93-Announcement* of Nov 92-All networks * April 94-Transition award to ATT, et,al. use T3 complete? -------------------------------------------------------------------------- REGIONALS Regionals will be given some funds for connecting to a Network Service Provider (NSP) of their choice (process t.b.d.) or to a NAP Subsidy funds for connecting to the NSP or a NAP will decline to $0 by 1996. (e.g. 100% 1st yr, 60% 2nd yr,...). Can change network provider selection ---------------------------------------------------------------------------- What can we do to prepare for the transition? We must focus early on communicating any technical concerns to our management and NSF, specifically relating to open issues that are yet unresolved and may affect each of our network's: Operational viability How do I coordinate inter-regional diagnosis and repair of end -to-end connectivity problems: Will I have to deploy new trouble ticket system? What are the performance and availability requirements for NAP participation: How will they be measured and reported: Who specifies these criteria: Who reviews submissions for connection? If I connect to NAP, will I have to deploy my own equipment there: If so, will there be someone there to act as my agent for repair and maintenance? Engineering plans How many NAPs will there be: (Will there be on close to me?) How should our network attach? Via a BB provider? Directly to the NAPs? Should I build a redundant connection to the NAPsL To my BB provider: Am I able to meet minimum requirements to connect to the Naps? (IDRP, CLNP, video, operations coverage) Do I need to negotiate, deploy, and manage N2 routing relationships if I connect directly to a NAP? To what extent must I be prepared to enforce policy routing: What choices will the RA provide my network or our clients regarding policy routing? policy routing? -------------------------------------------------------------------------- What can we do to prepare ...(cont.) Technical budgets - Personnel: How much extra operational staff will I need? Engineering staff? - Capital: Will I have to purchase new (or updated) boder routers: New network management stations and/or trouble ticket systems? - Operations: What new on-going costs must I budget for to pay for any new circuits? To pay for pro-rated NAP/RA costs? How will these costs be determined? We will need to significantly increase our intercommunications among attaching mid-levels and BB service providers to facilitate - technical transition planning and engineering - operations coordination, diagnoses and repair of peer routing instabilities, trouble ticket passing - end -to-end connectivity problem resolution - diagnosis and repair of peer routing instabilities After the contract has been awarded, we must be prepared to immediately participate in deployment engineering and planning with all other players (vBNS, NAP, RA awardees, NSF, other mid-levels). --------------------------------------------------------------------------- The view from a few steps back... Representative Boucher (chair of the House subcommittee that oversees NSF) from a speech made to National Net 92 on March 25: "In developing the detailed plan for transition to the NREN, I think a few basic principles must be observed. First, the benefits of this network should flow to the nation broadly and not just to a narrow few. The developments of markets and the involvement of industry [...] is essential. {The} development of the technology and management of the NREN should push the limits necessary to stimulate and meet the demand for services while ensuring reliability and stability to the users. And finally, the many communities that participate in the development and use of the NREN must have a voice in planning for the network and for its long-term management." 5.) Virtual Routes Presenter: Bilal Chinoy (SDSC) Bilal presented a paper that was published in ACM CCR in 1992, on his analysis of routing traffic on the NSFNET backbone. His premise was that one can take advantage of destination locality in Internet traffic to design more compact forwarding tables. That is, one can keep the size of forwarding tables at about 20% of the total potential destinations and yet deal efficiently with all offered traffic. 5.) Current Status /Problems Mark Knopper (Merit), discussion leader This session covered the NSFNET network status, including recent events such as dismantling the T1 backbone, deployment of FDDI cards, current status and future plans. Discussion focused on the routing table size in the backbone routers operated by ANS, and how to manage this by phasing in the CIDR architecture. Mark's slides: Mark Knopper Current Status/Problems -Traffic Statistics -T3 Network Status -Upcoming changes on backbone -MBONE routing -Policy Routing Database Changes -Discussion -------------------------------------------------------------------- T3 Network Status -FDDI installations: Installed: NEARnet (ENSS 134) 12/8 Argonne (ENSS 130) 12/8 FIX-E (ENSS 145) 12/11 SESQUInet (ENSS 139) 12/22 Cornell (ENSS 133) 12/24 FIX-W (ENSS 144) 12/29 NWnet (ENSS 143) 12/29 Merit (ENSS 131) 1/8 Scheduled: WestNet (ENSS 142) 2/1 -Rcp_Routed and FDDI interAS metrics -10000 route capacity on RS/960 cards ------------------------------------------------------------------------ Upcoming Changes - Near Term (Feb-March) Internal route aggregation ("CIDR") Route caching AIX 3.2 Gated with BGP 3 -Medium Term (March-June) CLNP forwarding Dual IS-IS BGP 4 -Longer Term (July-September) IDRP ----------------------------------------------------------------------- IETF and MBONE connectivity -ANS testing T1 data compression devices -Alternatively second T1 will be installed at OARnet -MBONE: Recommend that all NSFNET Regionals support MBONE mrouted machine attached to DMZ, Distribute multicast from that machine to sites on campus and within regional. Obtain feed from another site with direct T3 backbone connectivity. ------------------------------------------------------------------------- Policy Routing Database Changes -New Informix/RS6000 database system almost ready(really). -Merit is working on automating the configuration process: -Parsable NACR -Shared Whois Project (SWIP) -"Config Ticket" system -Upcoming work -Policy specification -Route server configuration and further experiments ------------------------------------------------------------------------- Problems? -Backbone performance and reliability is good. -What has not gone well? -What else should Merit/ANS be working on now? Organizations represented at the meeting: CNRI, 3com, Wellfleet, IBM, MILnet, NIST, Sprint, US West, PSI, AlterNet, ESnet, ANS, SDSC, Merit, MichNet, WestNet, CICNet, LANL/NSF, BARRnet, NorthWestNet, Cornell, NEARnet, SESQUInet, NCAR, Los Nettos/ISI, NCSA, SURAnet, and MSC.