CIDR

Fri Mar 11 21:49:39 UTC 1994

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