Routing WG meeting minutes
Tuesday, 22 August, 2000, Toronto Joint Techs Meeting
WG Chair: ken lindahl <>

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
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 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.


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 (; 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

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.

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.)

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.

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).