This is only a rough draft - Megan 04/20/92 The BGP Deployment Working Group Meeting Summary Report Agenda: o BGP Deployment status and issues o Routing policy sharing mechanism o Next Phase NSFNET architecture discussion 1. BGP Deployment status There are more sites/regionals using BGP in production or testing since last IETF meeting when the group started. There are 22 regionals/sites (it was 8 last IETF) connecting to NSF/ANSNet are using BGP in production mode. Most of them are using cisco BGP2 (BGP version 2) with their collocated NSS/ENSS. Tow or Three sites are using gated with BGP1 or BGP2. MILnet started beta test BGP3 on T-20 router. There are 6 or 7 Milnet sites are using cisco to BGP3 with the T-20 router. The BGP pilot project for the Pan-European network (Ebone) is making progress. There are BGP peer sessions within European network. There are also a lot BGP testing take place within European networks. New developments in BGP implementation: Gated supports BGP2 and BGP3 now. It is in alpha version. CA*net is using this version to BGP2 with the NSS. cisco has 9.0 beta which supports BGP2 and BGP3. Tony Li at cisco did an interoperate test between the cisco and other type of routers with BGP implementation. The result is listed in Appendix D. Matt Methis of PSCNet gave a presentation of 'BGP Usage at PSC'. His slides are listed in Appendix C. 2. Routing Policy Description Form The Routing Policy sharing mechanism was discussed at the meeting. The purpose of developing such mechanism is for each network sharing its routing policy to keep a global routing view so each network could design and implement their policy routing to avoid inconsistent with the global routing. We start with develop a routing policy description form. It will be evolved to a information base to install these kind of information and make it available for general access. It will also define the processor to process the information and generate inconsistency should it occur. At the meeting, an initial draft routing policy form was discussed and agreed upon. The Routing form is included in Appendix B. Merit will create a directory on host nis.nsf.net to install this form for anonymous ftp. Merit will also create a mailing list for people sending the filled forms and install them in the directory for anonymous ftp as well. 3. The discussion of Future NSFNET backbone architecture and its routing issues Peter Ford led a discussion of the NSFNET recompetition architecture. His report is included in Appendix A. Appendix A. NSFNET recompetition, architectural considerations. Reported by Peter Ford, LANL. peter@lanl.gov The National Science Foundation reported on architectural considerations for the NSFNET recompetition which will occur during the mid-1992. Leading the discussion were: Robert Aiken (NSF) Hans-Werner Braun (SDSC) Peter Ford (LANL) Stephen Wolff (NSF) NSF expressed thanks to the many people who provided input into the process of developing an architectural model for the future NSFNET including Merit, the FEPG, the operators of the U.S. regional networks, the FARNET membership, and the Intercontinental Engineering and Planning Group members. The architecture discussion focused on an interconnection architecture for networks which either provisioned research and education networks or those who needed to connect to the research and education networks. NSF stated that they believed that it is critical for the U.S. R&E networks get provisioned out of the growing telecommunications base so that they could take advantage of the economies of scale available in the telecommunications industry. This should allow for maximizing the flexibility in choosing within a parameter space defined by bandwidth, cost, reliability, etc. The model was based on the notion of "network access points" (NAPs) which be a chunk of shared media where networks (regionals, national, international, multination corporate, etc.) could interconnect. The NSF will provide support for developing a management and routing coordination function at the NAPs. This would be done through a collaborative agreement under the name of "routing arbiter". The routing arbiter would provide routing support at the NAPs through the use of a route server box which could peer with the attached networks and send a "homogenized" picture of the routing topology dependent on the picture a network would want to see as previously negotiated with the routing arbiter. The NAPs would be the focal point for evolving the internet architecture as new technologies became available and needed to be incrementally introduced. The NAPs would be "NSF AUP free" so commercial traffic from a U.S. regional could go onto the NAP in the process of going to another network which carries commercial traffic. There would be greater than 4 and less than 17 NAPs and they would be geographically dispersed. The NSF recompetition will have at least 2 providers for national scale R&E traffic and they will connect to all the NAPs. The providers are free to connect to things other than NAPs, including regionals. The was an extensive question and answer session, where the core topics included: asymmetric routes and the problems these posed (Vince Fuller Stanford/Barrnet, Matt Mathis PSC, Milo Medin NASA) the issue of who could connect to a NAP (Dan Long, John Curran BBN/Nearnet) how the routing arbiter would be managed, with emphasis placed on the observation that the current Merit/ANS/NSF configuration did not have the regional networks in a position where they were the customers of the NSFNET backbone (Scott Bradner, Harvard/Nearnet). Steve Wolff commented that he would like to hear input on this topic. AUP issues Would regionals have to connect to a NAP? -- no. Overall management of the 2+ providers and the NAPs? NSF also stated that the need for maintaining the routing database that Merit currently manages would fall under the auspices of the routing arbiter. The session was well attended and the discussions were vigorous. The NSF would like to thank Jessica Yu for allowing them to barge into the BGP deployment group meeting on short notice, and would like to encourage any interested parties to contact the NSF with ideas, questions, and concerns (steve@nsf.gov, raiken@nsf.gov, peter@lanl.gov). Appendix B. Routing Policy Description Form (4/6/92) ------------------------------- A. General Description of your Autonomous Systerm (AS) * a. List the name of your AS and the AS number(s) b. List the Routing administrator of the AS Name: Organization: e-mail: phone number: c. List the networks that belong to your AS and mark them with RE or non-RE type if applicable d. List the name of your direct neighbor AS(s) and its AS number(s) e. List each IP address of your border router(s) which interface with your neighbor border router(s) and the Exterior Routing Protocol(s) used respectively. f. Is your AS a Stub AS? Multi-homed Stub AS? Transit AS? Pure Transit AS? g. List the IGP used within your AS (optional for a non-transit AS) h. Describe the maximum and minimum bandwidth of the transit portion of your AS (optional for a non-transit AS). i. Describe the delay characteristic of physical links of transit portion of you AS, e.g., satellite, terrestrial (optional for a non-transit AS). B. Policy Descriptions a. For all the ASes. o Outbound advertisement filtering: 1. list the set of nets belong to your AS that you do not advertise to your neighbor(s). 2. list the set of nets belong to your AS that you do not wish to be advertised to certain ASs. List the AS numbers. o Inbound acceptance filtering: list the set of ASs whose nets you do or (do not) accept from your neighbor(s) If AS number is not a satisfactory granularity, list the set of nets. o Describe your routing policy based on your Acceptable Use Policy (AUP): Does your AS accept: 1. all types of traffic? 2. only RE type traffic? 3. other? (please specify) o Does your border router default to your neighbor border router? If yes, described the mechanism. b. For Multi-homed Stub ASes only: o List the preference/denial of the neighbor ASs which can route your traffic to the same destination (Multi-homed AS only). c. For Transit AS only: o List the paris of source/destination ASs or nets that your domain does not provide transitivity. o List the preference/denial of the ASs which can route your traffic to a certain destination. _____________________________________________________________________________ Note: * The notion of Autonomous System(AS) here means the following: a. An AS is a network blob which has a coherent Interior routing plan and under single administration. b. the AS number will be in the BGP AS path Appendix C Matt Methis' presentation slide (Megan: it was sent you via Postoffice mail early this week, please insert it here. Thanks!) Appendix D BGP Interoperability Matrix Versions tested: a) cisco 8.2,8.3 - v2 b) cisco 9.0 (beta) - v2,v3 c) BBN T/20 2.0 - v2,v3 d) NSS/eNSS (???) - v1,v2 e) gated 2.x - v1 f) gated (alpha) - v2,v3 | a | b | c | d | e | f | ---+-------+-------+-------+-------+-------+-------+----------------- a | same | | | | | | ---+-------+-------+-------+-------+-------+-------+----------------- b | ok | same | | | | | ---+-------+-------+-------+-------+-------+-------+----------------- c | ok | ok | same | | | | ---+-------+-------+-------+-------+-------+-------+----------------- d | ok | ok | ? | same | | | ---+-------+-------+-------+-------+-------+-------+----------------- e | vers | vers | ? | ok | same | | ---+-------+-------+-------+-------+-------+-------+----------------- f | ok | ok | ? | ok | vers | same | ---+-------+-------+-------+-------+-------+-------+----------------- Status: ok - interoperability tested, found to work same - same version, interoperability assumed vers - lack common version ? - unknown Tests: Establish connection. Negotiate version (if applicable). Exchange routes.