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

Should be 'word' instead of 'work'. A real bad typo. It means all the ASs (exclude the ones which have no Internet connection) should be either CIDR capable or defaulting. >>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.

I guess the question should be asked is that if most people feel comfortable enough to advertise aggregate yet? Look at AS690's, many sites have already BGP4 with AS690, but few advertises aggregate. Look at the whole internet, how many ASs advertising aggregate right now? >>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. :-)

If 131.108 is really critical to my user, I will hate to have my user loose connectivity and yell at me. I'd do some work to anticipate the problem if there is any. I will do a traceroute to see what ASs my traffic to 131.108 traverses and find out the potential CIDR blackhole. Knowing 131.108 will be pulled out proir to its happening does give me advantage. If I do not care the destination that much, then I could wait until my user cry like you suggested. So I am still in favor of to have the information available in advance. --Jessica