Jessica,
The issues, which I can think of for now, needs to be addressed here are: 1. Make sure no non-private ASs which are neither CIDRized nor defaulting to other ASs.
Given the size and the distributed nature of today's Internet, what you proposing doesn't seem to be a tractable problem. A more relevant, and certainly more tractable problem would be to find out whether all the ASs *directly* attached to AS 690 are either (a) CIDR-capable, or (b) point default to AS 690 or some other AS, and whether these ASs can register their CIDR prefixes with the MERIT Routing Policy Database today. Could MERIT provide us with this information ?
2. Gain more confidence with the newly deployed CIDR in the networks. More aggressive testing; injecting test CIDR routes to the Internet...
While I have nothing against the concept of gaining "more confidence", I think that the "more aggressive testing" phase is already in the past. At this point I don't see "injecting of test CIDR routes to the Internet" as a valuable way of spending our resources. A better way to spend our resources and to gain *real* confidence with the newly deployed CIDR is to follow the strategy used by Havard: 1. Announce a CIDR aggregate 2. Remove individual components of the aggregate and test its impact on the connectivity. I would assume that Havard already has some form of a script that allows to test the connectivity, and that this script could be easily modified for use by other sites. While the test done by Havard doesn't guarantees that removing the individual components has no impact on *any* of the hosts in the Internet, it tests for the impact on connectivity to a good sample of the Internet. We need to understand that providing the former (a priory information on whether removing the individual components would impact connectivity to *any* host in the Internet) is an intractable problem, while providing the latter (assessing the impact of removing the individual components on connectivity to some sample of the Internet) is certainly doable (as shown by Havard).
3. Establish procedures for ASs to announce the replacement of individual net routes to aid the detection of potential impact/of removing such routes from the Internet. .... Is 3 days in advance reasonable ?
Announcing the replacement of individual components to the BGPD mailing list is a fine idea, but it seem to me that we don't need any special procedures for doing this (after all, all what it takes is just a piece of e-mail, and that is exactly what Havard did). With respect to whether "3 days in advance" is reasonable, we'll be better off by sticking with Havard's strategy, instead of dwelling on this topic. Yakov.
participants (1)
-
yakov@watson.ibm.com