Route aggregation in BIRD - how?

[Alexander V. Chernikov]

On 16.01.2013 04:55, Ondrej Zajicek wrote:
> On Wed, Jan 09, 2013 at 04:12:48AM +0400, Alexander V. Chernikov wrote:
>> Version 7 :)
>> Changes
>> * Fix bug with using 0/0 and :: in aggregation protocol
>> * Fix mandatory lists not working before second rehash
>> * Improve docs and configuration example a bit
>> * Some code cleanups
>>
>> Thanks to Robers Hass for his bugreport and testing.
> 
> 
> Hello
> 
> I would like to merge the aggregator, but i have three related
> conceptual problems with your patch:
> 
> (1) About third of the code is related to BGP attribute processing
> according to RFC 4271 9.2.2.2 (esp. AS_PATH merging and AS_SET
> construction) for 'save attributes' option, but this behavior is IMHO
> mostly useless, as such behavior is deprecated, RFC 6472 recommends that
> AS_SETs should not be generated and there is a RFC draft [*] that
> even prohibits them. As this feature adds significant and unnecessary
> complexity, i would like to remove it.
Okay, that's absolutely fine for me.
> 
> [*] http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-01
> 
> (2) If i understand it correctly, your aggregator keeps a copy of all
> received and aggregated routes in an internal fib, which is useful for
Actually, not all: only routes which are more-specific for any summary
or mandatory ones.
> implementing (1), but unnecessarily if you just want to originate an
> aggregate route if there are some matching routes (or required number of
> mandatory routes). In that case you just need some counters for summary
> routes and flags for mandatory routes. Current implementation is especially
> memory wasteful in the common case 'aggregate full BGP feed to get a default
> route'.
Well, aggregating default without any filters is a quick and wrong way
of generating summary since
1) you have at least aggregate RTS_BGP routes only
2) If ISP fails probably either session goes down or full-view
disappears leaving _some_ (IX or provider-own) routes.
3) Additionally, sometimes ISP can loose transit to foreign countries
leaving national routes intact

So I assume someone to configure filter with several stable prefixes
(most valuable from user point of view) while doing default aggregation.
In this case, memory usage is not so wasteful. Additionally, copying
attributes increments their refcount for the most cases (or am I wrong?).

We probably can consider implementing additional something like 'min
count XXX' summary route attribute to ease aggregating default route.

> 
> (3) Generated aggregate routes have attrs->proto->proto == proto_agg,
> but attrs->source == RTS_BGP. What is a reason for that? It does not
AFAIR it is the artifact from one of the first versions without generic
aggregation proto.
> make much sense to me, because it does not have true BGP route behavior
> (for example rte_better would not compare it with others because of
> attrs->proto->proto) so i see no reason why not to define RTS_AGGREGATOR
> and use it. Even if we would like to generate BGP-style aggregated routes
> with BGP_AGGREGATOR and BGP_ATOMIC_AGGR attributes.
> 
> 
> There are some minor issues (e.g. there is probably a bug in
> bgp_update_sumroute() in BGP_ATOMIC_AGGR generation - even if not
> received from aggregated routes, this attribute should be generated if
> BGP routes with non-empty AS_PATH are aggregated and 'save attributes' is
> disabled), but these probably aren't problematic.
> 
> 
> If you do not have strong objections, i would remove (1), do some
> readjustment for (2), fix some minor issues and merge it. Question is
> whether there is any need to have optional keeping a copy of child
> routes in (2) for some sophisticated aggregation modes like (1), but
> without (1), i currently don't see the need.
The only thing I see is generic FV compression to fit in small FIB, but
this requires additional amount of work to be done, so I'm not against
removing.

Btw, I can do (1), (2) and implement this 'min count' stuff to further
move to the review-based approach instead of you constantly fixing my
mistakes yourself :)
> 
> 


-- 
WBR, Alexander