Route aggregation in BIRD - how?

[Alexander V. Chernikov]

Ondrej Zajicek wrote:
> On Mon, Jan 23, 2012 at 10:30:48PM +0400, Alexander V. Chernikov wrote:
>> On 23.01.2012 22:00, Ondrej Zajicek wrote:
>>> On Mon, Jan 23, 2012 at 08:14:28PM +0400, Alexander V. Chernikov wrote:
>>>> On 23.01.2012 20:01, Maciej Wierzbicki wrote:
>>>>> Hello.
>>>>>
>>>>> Case study:
>>>>> * importing full BGP table from various uplinks
>>>>> * some routes received by BGP are being exported via OSPF to core1,
>>>>> using filters:
>>>>> (source = RTS_BGP&&  bgp_path ~ [= * ASNXYZ * =])
>>>>>
>>>>> Question: how to aggregate routes (whenever possible) before exporting
>>>>> them via OSPF to core?
>>>> It is not possible currently.
>>>>
>>>> I'm working on BGP route aggregation and I plan to get more or less
>>>> working code at the end of this week.
>>> Do you plan to integrate it to the BGP protocol? I don't think it is
>> This is separate protocol, of course.
>>> a good idea. It would be easy to make generic route aggregation -
>> My first idea was to implement generic aggregation protocol.
>> However, do we really need it generic?
>> Currently we have bunch of link-state protocols (ISIS / OSPF) which are  
>> pure singletons, and, even if not we probably don't want to make summary  
>> routes between instances. RIP[ng] is RIP(c). There are also some  
>> multicast protocols but is is far-far away. Not sure if we should permit  
>> route aggregation from different protocol types.
> 
> My idea is to to make this independent of a source protocol of
> aggregated routes. So the question would be: Is there any advantage to
> make it specific? Generally, the aggregator would accept any routes and
> generates a new one, without any protocol specific attributes. There may
> be an option for processing BGP attributes and generating proper BGP
> attributes, but i guess this is not essential.
> 
> I guess most users would want either aggregate received BGP routes to
> generate the default (or some more specific) routes for IGP (for this
> usage pattern it would be useful to have option for mandatory minimal
> number of routes to originate aggregate), or aggregate their IGP routes
> for origination to BGP.
> 
>> Yes. I personally see this as following:
>>
>> protocol abgp agg1 {
>>   aggregate address  1.2.3.0/24;
>>   aggregate address 1.2.4.0/24 save attributes (or other keywords); #  
>> Aggregate as much attributes as possible ( see RFC 4271 9.2.2.2. )
>> #  
>> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094826.shtml
>>   aggregate address 2.3.4.5.0/24 summary only;
>>   aggregate address 3.4.5.0/24 mandatory list { 3.4.5.1/32, 3.4.5.8/29};
>>   import filter somefilter; # Change summary route attributes
>> }
>>
>> protocol bgp bgp1 {
>>   ..
>>   aggregator agg1;
>> }
> 
> 
>> Rte's matching 'summary only' instances have to be modified (no-export  
>> community have to be added to community attribute) by aggregator before  
>> passing them to rte_update
> 
> What about just having an aggregator protocol connected directly to a
> table? Routes would be received from a table and aggregated ones are put
> to the same table. This would work well for BGP->IGP and IGP->BGP
Yes, if we assume protocol instance can aggregate any routes we can use
singe instance per rtable and add pointer to it inside struct rtable.
First disadvantage is that protocol lost last bits of knowledge about
aggregation. I mean, in this approach we will do tree checks for every
         best rte regardless of protocol type. We still have to add
no-export community to matching rtes for supporting summary-only routes
(nearly the same task as in discussion about LDP.label attribute).
The second one is summarized attributes:
1) We have to announce summary rte with some source (RTS_). If we're
aggregating BGP routes it is BGP. And if we get 3 BGP and 1 OSPF ?
We can't detertmine it reliably.
2) If we try to save attributes as much as possible (AS-PATH / AS-SET,
even communities) we can end with route having both OSPF metric, for
example and BGP attributes.

So in this approach we have to change syntax to

proto aggregator agg1 {
  aggregate-address bgp 1.2.3.0/24;
}

or even

proto aggregator agg1 {
  bgp {
    aggregate-address 1.2.3.0/24;
  };
  ospf {
    ..
  }
}


> aggregation, where we do not care for non-aggregated routes. Not sure
> about BGP->BGP transit, but i guess it could also work, or aggegator
> could work like a pipe. Not sure if my explanation is clear enough, i
> could add some examples.
> 
>> Aggregator stores its summary and mandatory routes in modified f_trie.
>> (
>> I think, there is no need to import/implement another tree if we can
>> modify current implementation:
>> e.g. use regular pools (flag passed to f_new_trie, along with node_size)
>> and add trie_remove_prefix
> 
> OK
> 
>> Btw, I've got small patch from my previous approach, it moves default  
>> protocol preference to struct protocol and assigns it in  
>> proto_config_new instead of assigning it in every protocol manually.
>> Maybe it is a good candidate for the next commit? :)
> 
> Merged.
Thanks!

Maybe another simple patch? :)
It shows "UNNAMED" as filter name instead of <NULL> where protocol
filter is configured as input filter { ... };
(It is patch #2 from general protocol limiting patch tale)

Btw #2,
And. there is another patch that removes [nearly] all pipe hacks from
core, can you take a look at it? (I've sent both patches on 29 october
with last limiting patch version) (And I probably know now how can I fix
last FIXME)

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yandex-Fix-BGP-filters-naming.patch
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120125/3e4f4577/attachment-0001.ksh>