1. Make sure no non-private ASs (for lack of a better work) which are neigher CIDRized nor defaulting to other ASs. Err, could you restate that? I'm having a bit of a problem parsing this. 2. Gain more confidenece with the newly deployed CIDR in the networks More aggressive testing: injecting test CIDR routes to the Internet, announce it to the bgpd list along with a couple of pingable hosts in the aggregate. Haven't we done enough of this already? I think that EVERY site should go through this phase to verify their configurations and make sure their neighbors aren't doing anything stupid, but I see no need for a site that has been CIDR-clueful for 6 months to continue pussyfooting about. 3. Establish procedures for ASs to announce the replacement of individual net routes to aid the detection of potential impact/probl of removing such routes from the Internet. Andrew(?) suggested that ASs announce to the bgpd mailing list the list of individual intented to be replaced by an aggregate route several days prior to the remove. This should be a good start, shall we agree on do that? Is 3 days in advance reasonable ? Is everyone in the world (or at least on bgpd) going to go to the trouble of checking to see if they have a -correct- aggregate route covering the individual networks and report problems if they do not? Furthermore, if they don't have the route, what tools are there in place for tracking down the lack of said route? If I'm advertising 131.108.0.0 and 131.109.0.0 and I want to replace them with 131.108.0.0/15, we can't track down the AS who is swallowing the CIDR route until we actually rip out one of the less specific routes. Given that hurdle, I suggest cutting the administriva and yanking the less specific routes at a nice slow managable rate and watching the fireworks. Then we send neutron tipped traceroutes to anyone who is still blackholing CIDR connectivity. :-)