CIDR Aggregation Tool
cengiz at ISI.EDU
Wed Nov 29 17:33:33 UTC 1995
Curtis Villamizar (curtis at ans.net) 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 Alaettinoglu Information Sciences Institute
(310) 822-1511 University of Southern California
More information about the NANOG