CURRENT_MEETING_REPORT_ Reported by Susan Harris/Merit, Elliot Schwartz/UUNET Canada and Tony Li/cisco Systems Minutes of the Inter-Domain Routing Working Group (IDR) First Session -- Tuesday, 4 April This first of three IDR sessions was comprised of three presentations: o Selective Updates in Inter-Domain Routing o A Further Application for RIFs: De-aggregation in ATM Clouds o BGP/IDRP Route Server Proposal Each is briefly summarized below. Selective Updates in Inter-Domain Routing By Kannan Varadhan, USC/ISI (presented by Ramesh Govindan, USC/ISI). This presentation focused on Routing Information Filters (RIFs), which make it possible for an entity that participates in inter-domain routing (either via BGP or IDRP) to specify additional routing information it wishes to receive from a peer. RIFs are described in detail in ``Extensions for Selective Updates in Inter Domain Routing,'' draft-ietf-idr-rifs-00.txt, by Yakov Rekhter, Kannan Varadhan, and Curtis Villamizer. RIFs can be used to obtain routing information that might otherwise be lost through aggregation or by the dropping of multiple routes to a given destination by an intermediate router. Ideally, the price for obtaining the information would be paid only by the domain that desires it. One solution for obtaining the data might be to query the domain where the information loss occurred for more detailed information. However, this method would incur some cost for the routers where the information loss occurred. It addition, both routers must speak a common protocol, such as BGP or IDRP. RIFs present an ideal way to obtain the information. RIFs are based on NLRI (Network Layer Reachability Information), and not on other route attributes. RIFs are applicable to both BGP and IDRP, and work with CIDR. As described in the draft specification, a RIF is a tuple of the form . Govindan described each component in detail. He then outlined methods for carrying RIFs in the BGP/IDRP OPEN message, the BGP UPDATE message, and the IDRP RIB_REFRESH message. He concluded by describing the application of RIFs in ERP (Explicit Routing Protocol.) A Further Application for RIFs: De-aggregation in ATM Clouds Curtis Villamizer, ANS, began his presentation by enumerating three factors that affect route scaling problems: the number of routing adjacencies, the number of routes (or amount of state required), and the volume of route change. He then discussed a typical NSP's view of Internet routing, and noted that on average there are 2.5 paths per for each NLRI. He described scaling problems in a full mesh IBGP, and discussed aggregation problems for single-AS and multiple-AS route servers. Villamizer's comments on scaling problems for inbound aggregation of hosts and outbound aggregation to hosts and routers provoked a lively discussion among attendees of the problems of defining a mechanism for cut-through and de-aggregation. Villamizer strongly recommended that inbound aggregation of routers should not be performed, since this can lead to a very large number of adjacencies. He noted that the following actions should be taken to de-aggregate using RIFs: 1. Look up the route and determine the next hop (NH). 2. If the NH has the ``SameNBMA'' attribute, open a BGP adjacency with the aggregator and send a RIF with the destination. (As defined in RFC 1583, NBMA refers to the Non-Broadcast Multi-Access network, e.g., X.25, SMDS, Frame Relay, and ATM.) 3. If a more specific route is returned with ``SameNBMA,'' repeat step 2. 4. When the most specific route for the destination no longer has the attribute ``Same NBMA,'' stop and use that next hop. Villamizer also noted that several issues remain for the next version of the RIF draft. These include: o Host and route actions need to be described in detail. For example, RIF responses should never be readvertised in BGP routes, and should not be placed in the Local RIB, only in the FIB. The draft would benefit from a clear description of how to determine when a next hop can be further refined, what to put in the RIF request, the actions taken by an aggregator responding to RIFs, and the actions taken when RIF responses arrive. o BGP attributes are needed for the originator's media address, to identify RIF responses, and to specify missing sets of routes. BGP/IDRP Route Server Proposal Dimitry Haskin's proposed Route Server (RS) differs from multi-view RSs, like those deployed at the NAPs (Network Access Points), in that it does not perform any route selection, but only relays routing information to its peers. Actual route selection and filtering is performed by the client routers themselves. The proposed RS emulates full mesh peering. Individual RSs can be grouped into RS Clusters that share the same subset of client routers. A cluster with more than one RS provides redundancy of routing information to its client routers. Second Session -- Wednesday, 5 April Agenda o BGP/IDRP Route Server status o BGP Communities o Routing Confederations o AS Guidelines o BGP-4 to Full Standard BGP/IDRP Route Server Dimitry Haskin's Internet-Draft, draft-haskin-bgp-idrp-mesh-routing-00.txt, will be submitted as an Experimental RFC after review by Dennis Ferguson. This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers. The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g., an ATM cloud). BGP Communities Paul Traina, cisco Systems, presented an overview of the Internet-Draft, draft-chandra-bgp-communities-01.txt. This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet. Cengiz Alaettinoglu/ISI brought up the idea of putting in a provision for defining intersections and unions of communities (for aggregation purposes). Jon Postel agreed that the IANA would take care of registering BGP attribute numbers. A list of the currently used ones needs to be sent to him. Andrew Partan asked about methods of grouping communities. Paul said there could be a way to delete or modify a range of communities. There was a discussion on what to do with the Internet-Draft. Dimitry said Bay Networks could implement this attribute. It will be moved to an Experimental RFC after being reviewed by Dennis. Routing Confederations Paul Traina presented an overview of the Internet-Draft, draft-traina-bgp-confed-02.txt. This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation. The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. Yakov Rekhter asked if the internal AS numbers should come out of a private address space, similar to IP addresses under RFC 1597. Consensus was that this is a good idea. Vadim Antonov mentioned confederations would help in identifying who uses what AS numbers (i.e., a network provider would appear to be one AS externally). He said that Sprint uses something like this in production, and that it helps with routing convergence since next hops are consistent. It was noted that the current cisco implementation requires that all the routers in a confederation be aware of this. This could be fixed. Paul will do more research before this Internet-Draft is submitted as Experimental. AS Guidelines John Hawkinson provided a brief recap of the Internet-Draft, draft-ietf-idr-autosys-guide-02.txt, and discussion to date. Peter Lothberg agreed with the aim of the paper in general, but was unhappy with how it had been used by the RIPE NCC. He spoke about a specific case in which an AS number was refused (based on the content of the paper), where he considered it legitimate. A discussion about Peter's case, the role of registries, and the possibility of AS number exhaustion occurred. Most people felt that the registries should use this document in assignment. The creation of a private AS number space for use in confederations was discussed. It was suggested that we ask the IANA to set aside the top 1K AS numbers for this, and reserve the top 8K in case. The exact numbers will be discussed off-line and reported to the IANA. It was suggested that transit providers should probably filter these by default (like IP numbers under RFC 1597). Consensus was to send this Internet-Draft to the IESG for consideration as a Proposed Standard, as soon as final editing was done. BGP-4 to Full Standard The whole Internet runs BGP-4, and there are multiple interoperable implementations. The document was a Draft Standard at the last meeting. Paul will update the experience document. If there are any new implementations (besides those mentioned in the document), people should send e-mail to Paul. Editorial changes should be sent to Tony Li and Yakov Rekhter. There is a need to clarify (a) handling of unrecognized optional parameters in the OPEN message. There is also a need to add text on suppressing routing information looping. There was consensus that BGP-4 should be a Full Standard by the next IETF. Third Session -- Thursday, 6 April Agenda o IDRP for IPv4 and IPv6 - Performance related attributes for IDRP - BGP AS Path Metrics IDRP for IPv4 and IPv6 -- Paul Traina o Add parameters to open and refresh message so that they are extensible. o Parameters use standard IDRP TLV layout. o Add support for QOS attribute, residual error attribute, transmit-delay attribute. o No support for distinguishing attribute. o Support for IPv4 transport. o IPv4 prefixes or AS numbers may be RDIs. o Need to add soft notifications. Performance Related Metrics in IDRP -- Paul Traina o Add global notions of bandwidth and delay to updates. o Simplifies global optimization. o Cannot easily use true capacity due to load fluctuations and route flap. BGP AS Path Metrics -- Tony Li o AS path metrics. o There was a concern that this would increase flapping due to the dynamic nature of the metric. Limit propagation of change to the dynamic part.