Routing WG meeting minutes
Monday, 30 October, 2000, I2 Members Meeting, Atlanta.
WG Chair: ken lindahl <lindahl@ack.berkeley.edu>.
Minutes written by ken lindahl, 2 Nov 2000.
Please send any corrections/additions to <lindahl@ack.berkeley.edu>.
----------------
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: <abilene-routing@internet2.edu>. 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.