CURRENT_MEETING_REPORT_ Reported by Dave Katz/cisco Systems Minutes of the joint session of BGP and IPIDRP Working Groups Call to Order Susan Hares, Chair of the OSI IDRP for IP Over IP Working Group (IPIDRP), and Yakov Rekhter, Chair of the Border Gateway Protocol Working Group (BGP), called the meeting to order. Dave Katz agreed to act as recording secretary. The following agenda was presented: o BGP4 progression to Proposed Standard o BGP4 MIB progression to Proposed Standard o BGP/IDRP policy MIB o BGP/IDRP over X.25 o IDRP status o IDRP for IP next step o IDRP for IPng BGP4 Progression to Proposed Standard Yakov described the requirements for progressing a document to Proposed Standard status. One of these requirements is a report to the Routing Area Director describing, among other things, implementation experience. Yakov solicited an implementor to write this report and Paul Traina graciously volunteered. BGP4 MIB Progression to Proposed Standard Yakov reported that no comments were received on the Internet-Draft MIB, and that no implementations are currently known, although it is reported that several implementations are underway. Once implementations appear, the required report will be written, and the document will be progressed at that point. BGP/IDRP Policy MIB John Krawczyk was asked by Yakov shortly before the meeting to report on Wellfleet's implementation of BGP policy control via SNMP. John described the following elements of Wellfleet's proprietary policy MIB: o AS Weights Table A one-to-one mapping between AS numbers and "weights" (or infinity). The weight is calculated over the path to the AS, and the path with the smallest weight is used. This is currently implemented for BGP3. o Import Filter Combinations of the network number, originating AS number, peer IP address, and origin attribute are matched to incoming routes. Possible actions are to ignore the route, or assign a route preference. Default is to ignore routes. o Export Filter Combinations of network number, source protocol, outbound peer AS, peer IP address, OSPF type, and OSPF tag (the tags can be automatically generated). Possible actions are whether or not to propagate, set the inter-AS metric (currently hardcoded but could potentially be synthesized from the IGP path cost), set the origin attribute, and assign an AS number (if the origin is set to EGP). A discussion ensued about the practicality of standardizing a policy MIB. There is a tension between trying to provide a mechanism by which a router can be completely configured using SNMP, and the fact that policy mechanisms are product differentiation features that are likely to differ from vendor to vendor. A standardized MIB would be an advantage operationally, but it is likely to be difficult to describe a canonical MIB that would reflect the breadth of functionality available in all implementations. One possibility would be to define a standard canonical subset of functionality and then use proprietary MIB branches for features unique to particular implementations. As there are very few policy MIB implementations at this point in time, it was agreed to table this topic until more implementations are available, at which time the issue will be revisited. BGP/IDRP over X.25 Gerry Meyer described a scheme for use of BGP over tariffed switched circuits, including X.25. There is a general problem with protocols that send periodic messages, in that they tend to hold switched circuits open forever, and generate lots of (potentially costly) traffic. They also may require full mesh connectivity, which requires many circuits. An Internet-Draft has been published that describes a mechanism for running RIP in such environments. Gerry described an adaptation of this mechanism to BGP: o Most behavior would be similar to current practice: - Exchange of messages to open and confirm connection parameters - Initial data flow of entire BGP table - Incremental updates sent as the routing table changes - Use of TCP to provide reliable delivery o Some things would need to change: - No periodic keepalives - Holding timer would not normally be running - On sending an update: * Start holding timer * Poll TCP to see if data got through * Cancel holding timer if data got through * Follow current practice if holding timer expires (tear down BGP connection) - Use of "circuit down" indication from circuit manager: * BGP would start holding timer and follow normal behavior on timer expiration * TCP connection should be notified to not attempt to send Circuit manager attempts to reestablish connection - Use of "circuit up" indication from circuit manager: * If holding timer still running (temporary glitch), holding timer is cancelled * TCP would forward queued data * If holding timer expired (longer term problem), equivalent to starting from scratch Susan pointed out that a similar scheme for IDRP has been published by the Aeronautical Telecommunications Network forum. A discussion ensued about how this type of functionality could be accomplished with minimal changes to BGP itself. It was decided that the only necessary functional change to the BGP protocol would be to specify that a negotiated holding timer value of zero would indicate that periodic keepalive packets are not in use. Other functionality would be part of a connection manager which would not be specified by the BGP Working Group, although the functionality expected by BGP would be. Gerry agreed to modify the BGP usage document to specify the expected connection manager functionality. Yakov agreed to make the holding time modification to the BGP4 document. BGP Working Group Status Tony Li moved that the BGP Working Group status be changed to ``hiatus.'' Yakov pointed out that this does not mean that the group is disbanding, but rather that it will lie dormant until it is necessary to resurrect it (in particular, to advance documents through the standards track). The group agreed by consensus. IDRP Standard Status Dave Katz reported that the IDRP specification, ISO 10747, had passed the DIS ballot and the document editor had accommodated all ballot comments. The final IS text was sent to the ISO Secretariat in Geneva this week, and ISO will formally ratify the document during the next ISO SC6 meeting in Seoul, South Korea in October. It was announced that an ASCII version of the IDRP document, to be published as an RFC, had been created by the document editor and was available on the ISO document archive on merit.edu. IDRP Usage Document The question was raised as to whether IDRP requires a usage document, distinct from the BGP usage document. It was noted that IDRP has a number of features that BGP does not, in particular, Routing Domain Confederations and Distribution Lists, and that it would be useful for a usage document to discuss the use of these features. It was decided that there would be a unified BGP/IDRP usage document based on the current BGP usage document. Susan and John Scudder agreed to write this document; Tony agreed to review it. IDRP MIB A MIB document exists, with local MIB extensions. The question was raised as to whether it would be worthwhile to create a unified MIB document. It was agreed that the BGP and IDRP MIB documents would remain distinct. IDRP Implementation Status The Aeronautical Telecommunications Network standards specify IDRP over a fully connected SMDS-like network running without an intra-domain routing protocol. One European router vendor expects an implementation within ``eight to ten weeks.'' Two ports of gated are being worked on (Sun and Hewlett-Packard). CSC is doing a scratch implementation for the Federal Aviation Administration. IBM is also doing a scratch implementation, but stressed that this was not a product. The implementation is expected to become available (end of 1993). No implementation provides any significant policy functionality at this time. The IBM implementation is intended to support the full policy syntax specified in an appendix in the IDRP specification. No implementation, except for IBM, supports Routing Domain Confederations at this time, though all implementors plan to do this (especially since it is a mandatory part of the protocol). The IBM implementation will support Routing Domain Confederations as part of its initial release (end of 1993). IDRP is currently active in Europanet, connecting two parts of Europanet together. Susan asked for volunteers to provide information on implementation experiences to be provided in support of progression of IDRP for IP to Proposed Standard status. The group agreed to pursue this progression. IDRP for IPng Susan reported that IDRP has been offered to all of the IPng working groups as a candidate inter-domain routing protocol. The TUBA group plans to use IDRP; the SIP and PIP groups are evaluating the protocol. Susan is preparing an IDRP for SIP document. IDRP for IP Working Group Status Susan moved that the IDRP for IP Working Group be moved to ``hiatus'' status until the documents are ready for progression to Proposed Standard status. The group agreed to this proposal. The meeting was then adjourned. Attendees Bernt Allonen bal@tip.net Arun Arunkumar nak@3com.com Toshiya Asaba asaba@iij.ad.jp Dennis Baker dbaker@wellfleet.com Tony Bates tony@ripe.net Ronald Broersma ron@nosc.mil Thomas Brunner brunner@switch.ch Henry Clark henryc@oar.net David Conrad davidc@iij.ad.jp Tom Easterday tom@cic.net Hans Eriksson hans@sics.se Stefan Fassbender stf@easi.net Mark Fedor fedor@psi.com Dennis Ferguson dennis@ans.net Peter Ford peter@goshawk.lanl.gov Shoji Fukutomi fuku@furukawa.co.jp Vince Fuller vaf@stanford.edu Craig Haney craig@icp.net Susan Hares skh@merit.edu Frank Hoffmann hoffmann@dhdibm1.bitnet David Jacobson dnjake@vnet.ibm.com J. Jensen jensen@ic.dk Cyndi Jung cmj@3com.com Marijke Kaat marijke@sara.nl Dave Katz dkatz@cisco.com Sean Kennedy liam@nic.near.net Rajeev Kochhar rajeev_kochhar@3com.com Ton Koelman koelman@stc.nato.int John Krawczyk jkrawczy@wellfleet.com Tony Li tli@cisco.com Robin Littlefield robin@wellfleet.com Peter Lothberg roll@stupi.se Peter Merdian merdian@rus.uni-stuttgart.de Gerry Meyer gerry@spider.co.uk Keith Mitchell keith@pipex.net Ramin Najmabadi najmabadi@helios.iihe.rtt.be Peder Chr. Noergaard pcn@tbit.dk Michael O'Dell mo@uunet.uu.net Andrew Partan asp@uunet.uu.net Willi Porten porten@gmd.de Juergen Rauschenbach jrau@dfn.de Yakov Rekhter yakov@watson.ibm.com Georg Richter richter@uni-muenster.de Duncan Rogerson d.rogerson@nosc.ja.net Miguel Sanz miguel.sanz@rediris.es John Scudder jgs@merit.edu Henk Steenman henk@sara.nl Ed Stern els@proteon.com John Stewart jstewart@cnri.reston.va.us John Stewart Marten Terpstra marten@ripe.net Kamlesh Tewani ktt@arch2.att.com Richard Thomas rjthomas@bnr.ca Paul Traina pst@cisco.com Rene van der Hauw rene@geveke.nl Rachel Willmer rachelw@spider.co.uk Jessica Yu jyy@merit.edu Romeo Zwart romeo@sara.nl