Hi. As Sheri said we are working on setting up a meeting of the NSFNET Regional Techs in Boulder on January 21-22. We realize that there is a FARNET meeting at the same time, and our idea was that while there wouldn't be formal overlap of meeting topics or agenda, it might be nice to create possibilities for informal get-togethers. For example, evening meetings or weekend skiing including both FARNET (regional net management types) and Regional Tech people. The reason for this meeting is that we thought the regional techs should have some time to get together outside of the more general IETF context for more focused discussion, perhaps leading to specific actions. There were agreements in ORAD, NJM, and BGPD that we should target June 1993 as the timeframe for implementation of BGP-4 and route aggregation. This raises a host of issues and operational questions, and led in our discussions to proposed agenda below. Our idea was that we could nominate one or two people to lead each session, and also "pack" the audience with some friendly experts on the respective topics. So far we've heard from WestNet, SDSC, BARRnet, UIUC, Sprint/ICM, SESQUInet, NorthWestNet, Merit, ANS, ESnet and NEARnet, that they can indeed attend at this time. We'd like to hear some more confirmations before we send out the final invitation, just to make sure the date and place is ok with everyone. The US West folks have made a generous offer to provide conference facilities at no cost to us, and NCAR and WestNet are also participating in hosting sessions and activities. Following is the first cut at the proposed agenda. Happy Holidays everyone! Mark Topics for the Seminar: Focus of the the seminar is Operational planing for 6-8 months. 1.) Implementation of CIDR and Supernetting CIDR is billed as a short term solution, and to get started there are immediate operational actions needed. To quote V. Fuller, J. Yu and T. Li, 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." Subtopics to be covered include: - Phase-in of route aggregation - Policy configuration for aggregation - BGP-4 test plan - Requirement for renumbering 2.) Address allocation strategies with CIDR This session should cover the address administration aspects of CIDR. We will need to 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. Thus we are inviting the folks from the NIC and possibly the IANA. 3.) GIX, NAPs, Route Servers There have been several experiments to verify the technology that is to be used in the "Network Access Points" proposed by NSF, including tests of route server configurations and the "MAE-East" distributed network. The IEPG has proposed that the MAE-East be used as a Global Internet Exchange to allow European networks to connect in a common subnet in Washington DC. Since it is likely that more prototype or even production NAPs might be created in advance of the 1994 timeframe, it seems necessary for the network operators to understand the internet routing implications that may result. The purpose of this session will be to discuss upcoming activities to support routing on this network, and to solicit ideas on how the system should work. 4.) Current Status /Problems This session will cover the NSFNET network status, including recent events such as dismantling the T1 backbone, current status and future plans. In addition to a status report we would like to have a discussion of Merit's performance, what general problems have been encountered, and how service quality can be improved. 5.) Transition to "Next Generation NSFNET" 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, probably 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.