Routing WG meeting minutes
Monday, 30 October, 2000, I2 Members Meeting, Atlanta.
WG Chair: ken lindahl <>.

Minutes written by ken lindahl, 2 Nov 2000.
Please send any corrections/additions to <>.

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

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