Route aggregation in BIRD - how?

[Alexander V. Chernikov]

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.

> 'virtual' protocol similar to static, which generates aggregate routes
> based on its config and received routes

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

Mandatory list is a list of routes which have to exist before summary 
route is announced.

[BGP] protocols using aggregator will call rte_update_agg() instead of 
usual rte_update()

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
)


Possibly we have to implement some kind of lazy protocol name resolving.
I mean, add all "aggregator $proto_name" entries to linked-list with 
file/line data and do symbol lookup after configuration parsing is 
finished calling modified cf_error() if lookup fails.


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? :)

--
Alexander V. Chernikov
Yandex NOC
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0002-Assign-default-protocol-preference-via-proto_config_.patch
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120123/d16e50b7/attachment-0001.ksh>