Havard Eidnes <Havard.Eidnes@runit.sintef.no> writes: * * I think that this tool will not create aggregates where there exists * "holes" in the network numbers which are being routed (at least that was Correct. * what I heard last time; I have not actually used or read the program). * Such holes may be there because a site is temporarily unavailable, * because the network number hasn't been assigned yet etc. * * I have yet to see a tool which beats human knowledge when it comes to * determining which ranges can be announced as aggregates, especially when * the knowledge of the assignment status for blocks is known. The output * of such a tool should be taken mainly as "advice". * Definately, this is very much an indicator rather than gospel. * I will claim that there is nothing dangerous and certainly very small * inconvenience or cost involved in announcing such "holes" as part of a * CIDR announcement. Remember that we do it all the time when it comes to * non-assigned subnets of class B networks. Depending on your routing * policy, there may be small complications when a customer moves to * another service provider, but we all know that, right? Add to that that * you'll be able to assign new networks to your cursomers and route them * without having to modify your external announcements, and you have a * nice savings in the form of less work to do. * Sure but who is advocating not announcing holes. The problem is, is it possible to ever write a tool to know when an aggregate with holes can be formed or not ? * - Havard --T