Routing WG meeting minutes Tuesday, 22 August, 2000, Toronto Joint Techs Meeting WG Chair: ken lindahl <email@example.com> Minutes written by ken lindahl, from notes taken by Matt Zekauskas. (Thanks, Matt, for taking such excellent notes.) Attendee introductions. ---------------- Opening comments ---------------- There are new guidelines for WG operations and meetings, drafted by Russ Hobby and ratified at WG Chair meeting 8/21/2000. These are based on IETF WG guidelines and discuss WG operation and meetings, expectations of WG Chairs, and content of WG charters. The guidelines are on the I2 web site at http://www.internet2.edu/stage/html/working-groups.html All WG charters are being updated and will be put up on the I2 web site; WG Chairs agreed to have initial versions in place by the time of the Fall Members meeting in Atlanta, Oct 31-Nov 3. The Routing WG web page is at http://www.internet2.edu/routing/. At this time, it's still in draft, with many placeholder links; in particular, the link to the charter is empty. Open or closed meetings: previous WG meetings have been deemed closed; do we want to continue this? WG Chair proposed that meetings be considered open, unless there is understanding ahead of time that a meeting should be closed for a particular reason. Those present consented to this; WG members who were not present and disagree with this decision should send mail to the Chair or to the WG list. ---- I2db ---- Merit has proposed a routing registry for I2 members. Susan Harris of Merit presented the proposal. Merit is offering to operate the registry on one of their servers, and to provide NOC and helpdesk support. It will be RPSL only, not RIPE-181, consistent with the goal of converting all registries to RPSL. There is a lot of documentation of IRR and RPSL via the RADB web site (http://www.radb.net/); also, Merit is offering to conduct tutorials for I2 members. Members would be expected to move their existing RR objects from whichever RR they are using now, to the new I2db. Merit can provide some assistance for this; in particular, in cases where members are having trouble getting out- of-date information deleted from some of the commercial registries. The I2db would be free of charge, and would be mirrored in the RADB and perhaps other existing registries. Tools (e.g.: rtConfig) are available for automating generation of router configs from RPSL. Steve Corbato, Brent Sweeney, and ken lindahl noted that UCAID and the Abilene NOC strongly support the proposal. Currently, the NOC gets contacted when a connector needs a change to Abilene's policy for accepting route announcements; when this involves accepting a new prefix, the NOC must attempt to determine the appropriateness of the request. This often involves a three-way discussion between the connector, the NOC, and UCAID, since UCAID maintains the membership records. UCAID and the NOC are particularly concerned that large-scale acceptance of K-20 sponsored participants into Abilene will dramatically increase the complexity of Abilene router configurations as well as the amount of discussion required to approve requested changes to Abilene policy. UCAID and the NOC would like for such requests to go first to UCAID (probably Steve Corbato and Aimee Massaro), which would approve the request if appropriate. UCAID would make the change to the Abilene accept-policy in the I2db and the NOC would configure the Abilene routers to conform to the I2db. There was some discussion of how this might actually happen, including the notion that connectors route objects might include a UCAID address in the notify attribute, but no conclusion was reached. Numerous questions were asked and there was lengthy discussion. Susan will take unanswered questions back to Merit, and send the answers to the list. (She has also joined the list, so any new questions can be asked there.) Ive tried to incorporate most of the discussion into the preceding paragraphs, but several topics are worthy of explicit mention: IPv6 -- the question of RPSL support of IPv6 routing was raised. As Abilene implements v6 routing, it would be very helpful to have v6 info in the I2db; more convenient than maintaining separate v4 and v6 databases. it was noted that RPSL does not currently address v6 per se, but RPSL was designed to be extensible. The RIPE whois has hooks for IPv6 registry objects; route objects will not be any problem. Sites running production TLAs are currently required to operate a registry as part of the TLA delegation. Procedures and guidelines for using I2db for this might be an area for collaboration between the routing and IPv6 WGs. Explicit routing / MPLS VPNs -- when ER is available from the manufacturers, there will be a need for expressing ER policy in RPSL. There is likely to be a need soon for MPLS VPN capability, Specification of RPSL objects will be a topic for this WG, possibly in conjunction with IETF activities; also rtConfig and other RPSL-based tools will need modification to handle RPSL extensions. Populating I2db -- need to describe procedures for connectors and participants to move their existing IRR objects into I2db. (Also need motivation for them to do so. Saving $200/year is not much motivation for many participants.) Concern was expressed that this will "raise the bar" of complexity for some participants who may not have any experience with IRRs to date. WG should address this issue. The group hummed consensus for the Merit proposal, with the understanding that UCAID and the NOC would specify the procedures for connectors requesting changes to the Abilene registry object. (Suggestions from the WG will surely be appreciated. ---------- WG Charter ---------- The WG needs to update its charter, including the list of "current topics." ken lindahl had compiled a list of topics incorporating the topics from the old WG web page, suggestions from Guy Almes, and others. The group discussed each briefly and voted whether to keep the item on the updated charter. Explicit Routing: Still an active topic for some gigapops and participants; several vendors are actively pursuing solutions to this issue. Steve Corbato noted that the Abilene CoU might be amended to allow K-20 institutions to use Abilene; does this eliminate the problem we are trying to solve? ken noted that CalREN2 peers with ESnet; ESnet AUP imposes an ER requirement. There was some discussion of what would go into the charter: the WG can articulate the problem and provide feedback, but the solution is currently in the hands of vendors. It will be impossible to set dates, but WG can agree to test possible solutions as they become available. KEEP in charter. I2 RR: Discussed earlier in meeting. KEEP. Routing asymmetry: This refers to I1 vs. I2 routing asymmetry; c.f. Hank Nussbacher's presentation from Spring 2000 I2 member meeting. see http://www.internet-2.org.il/i2-asymmetry/index.htm. KEEP. Routing issues related to Abilene CoU and participation policy: Most immediately, this refers to the possibility of admitting K-20 to use Abilene, and the possibility of a 2-tiered routing policy: i.e. "primary" participants can talk to other "primary" and "secondary" participants; "secondary" participants can talk only to "primary" participants, not other "secondary." (Note: use of the terms "primary" and "secondary" is informal, not any sort of accepted I2 terminology.) KEEP. Ingress/egress filtering BCP for connectors: Not really a routing issue, even though the filters are implemented on routers. Could go to security WG. ken will discuss with Cliff Collins (Security WG chair). DROP (pending discussion with Cliff). Standardized BGP communities: There was some discussion of a proposal to use communities to indicate the nation of origin, but apparently that proposal had been knocked down before the WG meeting. Steve Corbato requested this topic be kept on the charter, with a description like discuss community value usage and potential new communities. It was noted that there is no action item at present. However, Abilene or gigapops or participants can put proposals before the WG for discussion. Brent Sweeney noted that the WG was influential in the decision to change Abilene communities from replace to additive. KEEP (without specific objective/milestones). Gigapop routing: The old charter suggested documents would be produced. Didnt happen and gigapop routing is clearly happening, even so. The ER bullet will be kept as it's own topic. DROP. Campus routing: General consensus was that this had turned out to not be much of an issue, and no one is asking for this. DROP. IPv6 routing: No collaboration with IPv6 WG to date: ken will discuss with Dale Finkelstein (IPv6 WG chair), see if there is any need. DROP (pending discussion with Dale). Internet address allocation and management: Overtaken by events. DROP. QoS routing: Larry Dunn noted two items from the QoS WG: 1) if bandwidth broker concept is to work, need to understand how to handle a request for say, 600 Mbps; 2) use of MPLS mechanisms to ensure paths for EF traffic. Consensus is that these are topics to be aware of, but are not routing per se. DROP (ken to discuss with Ben Teitelbaum, QoS WG chair).