|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: CIDR Aggregation Tool
Curtis Villamizar ([email protected]) on November 27: > [lots deleted] > Another way of estimating what can be aggregated is by determining > from how many places all of the components of an aggregate could be > heard in all backup situations. In some cases it might be reasonable > to drop some degree of alternate connectivity (fourth or fifth > preferred paths) and allow a number of holes (specifically aggregated > components). In principle this could be done algorithmically using > the IRR. In practice, you need to check with some of the parties > involved to make sure registered information (particialrly aut-num AS > peerings) are accurate beforehand. > > Using the IRR you (or we) can select candidates for aggregation and > then make sure the aggregation can really be asfely done. This is a > little different in than you estimate in that it the viewpoint is what > can we aggregate, rather than what might we see better aggregated in > the future. The bgp paths at major interconnects could form a useful > sanity check, making sure that AS paths do not conflict with IRR AS > peering information for any candidate for aggregation. > [lots deleted] Actually we are working on such a tool, that we call CIDR assistant. A pre-alpha release of this tool will be available before/during the IETF, and there will be a discussion of this tool in the RPS wg. This tool considers the topology and the policies registered in the IRR before suggesting potential aggregations. The amount of policy/topology that is considered is configurable. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz
|