CURRENT_MEETING_REPORT_ Reported by Steve Corbato/NorthWestNet Minutes of the CIDR Deployment Working Group (CIDRD) Initial Agenda o Status Report - Erik-Jan Bos o CIDR Survey Summary - Jessica Yu o Local Aggregation - Yakov Rekhter o Other Topics A joint session with the IDR Working Group was planned for the Thursday morning session. The aim was to advance CIDR along the standards path. CIDR Progress Report The principal thrust of Erik-Jan's talk was that the number of BGP entries is rising again on an apparent exponential growth curve. The rate of increase does not appear to be as rapid yet as that before the Seattle IETF in March 1994 and the subsequent decrease associated with the increased implementation of BGP4 and CIDR. Erik presented his data characterizing Internet routing table size at three distinct time points corresponding to the three IETF meetings held in 1994. His presentation slides follow these minutes. There was some general discussion of the possibility that the NSFNET AUP might be abandoned during the final months of the NSFNET transition. This would help several large ASs (e.g., AS 701) implement CIDR. Jessica Yu says Merit has made this request to aid its NSFNET operation. With the apparent partial implementation of CIDR to date and the reacceleration in routing table growth, the topic of proxy aggregation was raised. Erik's slides are available in PostScript form: http://surver.wind.surfnet.nl/sheets/sheets.html CIDR Survey Report In addition to the CIDRD Working Group, Jessica sent a survey on BGP-4 and CIDR topic to a list of various ASs. She received responses from 58 ASes between September and October 1994. Her presentation slides follow these minutes. Vadim Antonov announced that Sprint is now silently aggregating its customers' more specific routes in NACRs submitted to the PRDB. Jessica mentioned several policies of responding ASs. Three ASs mentioned that they ask new customers to renumber within the ISP's CIDR block addresses. Two ASs mentioned that they have a policy of mandating that their customers run BGP4 if BGP is required. These ASs will perform proxy aggregation if the customer is not BGP4-capable. Jessica listed commonly cited issues that prevent CIDR implementation: o ``Routing table explosion is not my problem'' o Expensive hardware upgrade to run BGP4 o Lack of documentation on CIDR implementation o Lack of in-house staffing within ISP to implement CIDR o CIDRization breaks MED o Not all router types support CIDR o CIDR-capable software distribution lags outside U.S. o Artificial policies prevent aggregation -- NSFNET AUP, but others Some discussion broke out concerning the topic of how CIDR impedes topologically based MED options. This can be solved by careful topological assignment of addresses. It was noted that cisco will document their route coloring feature in version 10.3 of cisco IOS. It was also mentioned that 3Com supports CIDR, but does not yet provide proxy aggregation and that Wellfleet does support CIDR in release 8.0. Jessica mentioned several suggestions received in the course of the survey: o More documentation (e.g., sample router configs) is needed o ISPs should strongly recommend that connecting ASs implement CIDR o Develop more diagnostic tools to aid the CIDRization process (e.g., ``show IP route aggregatable'' in cisco IOS) o Broaden knowledge of routing table size crisis o Provide free hardware upgrade to support CIDR o Use public ``shame'' to pressure non-CIDR ISPs to CIDRize o ISPs should convince/leverage customers to renumber into providers' CIDR block o Make IP renumbering easier The working group took as an action item to generate an Informational RFC on CIDR configuration and the pressing need for implementation. At this point, there was vehement discussion as to whether the current size of the routing tables merits a crisis response. It indicates that ASs may need to protect themselves instead of waiting for others to aggregate which led to Yakov's local aggregation presentation. Proxy Aggregation Yakov discussed the motivation for proxy aggregation: o Routing information consumes resources (e.g., memory, CPU, bandwidth, people). o These resources cost money. o Current Internet-wide connectivity is provided by a collection of independent, sometimes uncoordinated, and often competing ISPs. Yakov's case is based on the following assumptions. There is a need to match the volume of routing information with the available resources while providing connectivity service on a per-provider basis. The amount of resources required must be tied to the utility of routing information. Finally, there is a need to break the linear dependence of the routing information size with the size of the Internet. Hence, proportionality to the number of networks or the number of connected sites is not scalable. At present, proxy aggregation is a mechanism that allows for the aggregation of routing information originated at sites that are BGP-4 incapable. It is primary being used at the site level, but has proven to be a useful transition tool to a CIDR environment. The aggregation is currently controlled by the originator of the routes to be aggregated. The destination has full control over the aggregation. However, the destination derives little or no direct benefits while the process of aggregation requires extra work on the part of the originator. Thus, there is no feedback mechanism to promote aggregation. Yakov advocated the idea that local aggregation would reconnect the beneficiary of this process with the entity that actually performs the aggregation. In his view of local aggregation, the routes that a domain (e.g., ISP) advertises to adjacent domains (e.g., ISPs, leaf networks) form a part of the overall service package that the domain offers to these neighbors. As the services offered between domains are controlled by bilateral agreements, then the issue of routing information aggregation should be incorporated into these agreements as well. Hence, a domain's aggregation policies are established on the basis of its bilateral agreements with its neighbors, thus preventing ``over-aggregation.'' In this manner, aggregation would become a local issue for each domain. There are two potential scenarios for local aggregation. Aggregation on entry is performed by the border router that receives route announcements from an adjacent domain. The action is purely local to the domain, but the reduction of routing information is beneficial to other domains as well. Aggregation on exit is performed by a border router that advertises routes to an adjacent domain. This process would be stipulated as part of the bilateral agreement. From the standpoint of reducing routing information, aggregation on exit is preferable, yet aggregation on entry provides more autonomy. Yakov identified several potential candidates for local aggregation: o Longer prefix addresses in presence of shorter prefixes o Adjacent CIDR blocks o Aggregation of known holes (i.e., unallocated blocks) Yakov concluded with the following points about proxy aggregation. The ASN and routing performing aggregation are identified via the BGP AGGREGATOR attribute. Each domain should register its aggregation policies in the RRDB. These policies will have been formulated to reflect the bilateral agreements in place with adjacent domains. During the post-presentation question session, Curtis Villamizar raised the issue that the Routing Arbiter could provide proxy aggregation upon request at the American NAPs and other exchange points. Also Geoff Huston advocated that ISPs that produce unaggregated advertisements around the network should face higher settlement charges from other providers Other Topics Tony Li raised the topic of CIDRizing the Class A domain space as the eventual exhaustion of the Class C address space is now in sight. A principal issue is the level of router software support for classless addresses. Geoff Huston noted that RIP remains the dominant IGP. Tony Bates called for more IGP education for the masses. Peter Ford advocated a 2-3 year advance notification for the deprecation of classful IGPs, but later modified the timing requirement to a trigger that would be dependent on an event horizon. As an action item, Sean Doran will generate documentation on the Apple Class A incident. In this case, a subnet of 17/8 was announced for Apple via a Texas ISP while Apple's primary connectivity was provided by a California ISP. As a result, classful routers could not reach the shorter prefix Class A for Apple, but the longest match to the subnet always worked. There was extensive discussion on the preparations necessary for Class A subnetting. Geoff Huston will document these by expanding a note written after the Toronto ALE Working Group meeting into an Internet-Draft. A proposal was made to announce Class A subnets there for global testing. In ALE discussions, Tony Li had advocated that the IANA should start assigning Class A subnet blocks.