Re: CIDR Aggregation Tool

[Cengiz Alaettinoglu <cengiz () ISI EDU>]

Curtis Villamizar (curtis () 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

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California
http://www.isi.edu/div7/people/cengiz