Routing WG meeting minutes Monday, 30 October, 2000, I2 Members Meeting, Atlanta. WG Chair: ken lindahl <firstname.lastname@example.org>. Minutes written by ken lindahl, 2 Nov 2000. Please send any corrections/additions to <email@example.com>. ---------------- Opening comments ---------------- A draft charter has been sent to the Area Director, Guy Almes, for approval. The charter contains three current topics: explicit routing (ER), Internet2 routing registry (I2db), and I2/I1 routing asymmetry. The charter is online at the working group home page: http://www.internet2.edu/routing/ Please review and send any comments or questions to the list or to me directly. There was a brief discussion of routing asymmetry. Mark Johnson has observed asymmetry between MCNC and NIH: packets from MCNC to NIH transited Abilene, in the other direction, packets transited vBNS. This was discussed briefly, along with the more general problem of asymmetry between I2 and I1, and between Abilene and CA*net3. Investigation of these issues is one of the current topics of this WG; see the draft charter. ---- I2db ---- The I2db has been created, along with the required supporting DNS records and email aliases. It appears that I2db is not being mirrored in the RADB (this is planned, however). Some very preliminary, very limited testing has occurred. (Curious readers can query for the "maint-iu" object: "whois -h whois.internet2.edu maint-iu" The charter specifies target dates for I2db adoption: in particular, we are looking for ten "early adopter" sites that will move their RR data into I2db by the next Techs meeting (Jan 28-31, 2000, Honolulu). Several sites were "nominated" from among the WG meeting attendees: Indiana U, U of Oregon, Advanced, and UC Berkeley. The WG chair will send mail to the list, describing the task and soliciting additional volunteer sites. UCAID and the Abilene NOC will use the I2db for making changes to the Abilene policy for accepting route announcements from Connectors. When a Connector needs to change the prefixes it announces to Abilene, the Connector must make the change to its "announce to AS11537" data. UCAID will review the change for appropriateness according to the CoU and make the corresponding change to the Abilene "accept from ASnnn" data; the NOC subsequently will make appropriate changes to Abilene routers' BGP configuration. A proposed mechanism for semi- automatic notification of these changes to the I2db was discussed. (see slides.) This proposal requires that Connectors include in their notification list the email address: <firstname.lastname@example.org>. The need for I2-specific documentation was once again acknowledged. The chair will solicit volunteers from the WG for the documentation effort. The need for training was also mentioned; Merit has offered to provide training in conjunction with member meetings and techs meetings. UCAID anticipates requiring Participants and Connectors to register their routing policies in the I2db in order to use Abilene. Connectors, gigaPoPs in particular, will have an active role fostering the adoption of the I2db, since it is Connectors whose registry data will contain "announce to AS11537" records. In particular, when a Sponsored Education Group Participant ("a SEGP"; this is proposed name for state-wide K-20 networks) wishes to use Abilene, the Connector will have responsibility for ensuring that the SEGP's routing data is correctly registered in I2db. Abilene applies both AS-path filters and prefix filters to BGP announcements from Connectors. This requires that Participants and Connectors list the prefixes they announce in their I2db objects. This will be a change for many if not most of the sites that currently use the RADB or another IRR. CA*net3 has it's own routing registry project, which Rene Hatem described briefly. The two registries should interoperate. Initially, use of RPSL will assure interoperability; however, later developments in either project could introduce interoperability issues. In particular, the CA*net3 project is considering the use of XML in registry objects. -------------------------------------- Implications of the changes in the CoU -------------------------------------- Steve Corbato gave a short presentation describing the implications of allowing general access to Abilene for K-20. Acceptable usage is summarized as: | destination | | EDU,ORG | COM,GOV | ITN P | ITN nonP | ------------+---------+---------+---------+----------| s EDU,ORG | Y + Y | Y + Y | o COM,GOV | Y + N | (Y) + (Y) | u ---+---------+---------+---------+----------| r ITN P | Y + (Y) | Y + N | c ITN nonP | Y + (Y) | N + N | e ---+---------+---------+---------+----------| ("ITN P" = ITN Participant; "ITN nonP" = ITN non-Participant; "Y" = allowed; "N: = not allowed; "(Y)" still unfinalized, Steve prefers allowed.) [Note: the International Transit Network ("ITN") agreements were not discussed in the WG meeting, but were discussed in several regular sessions. CA*net3, StarTAP, and Abilene have agreed to provide transit between participating international peer networks. In the case of Abilene, an MoU between Abilene and the international peer is required. An international peer is an ITN Participant by default; a peer must explicitly declare that it wishes to not participate in order to be considered an ITN non-Participant.] The requirement for COM sites to partition their networks between research/education vs. commercial parts has been relaxed: a .COM site can use Abilene generally in accordance with the acceptable usage shown above; however, .COM to .COM traffic still is not allowed to transit Abilene. Acceptable usage needs to be enforced by Connectors, gigaPoPs in particular; BGP communities will be used to tag prefixes. (pointer to list of communities.) Wrt SEGPs (see above), intra-state K-20 traffic cannot transit Abilene; this decision was made in order that use of Abilene not disincent states from the development of a functional, state-wide K-20 network. Similarity to Star Trek's "Prime Directive" was noted.