Route aggregation in BIRD - how?

[Ondrej Zajicek]

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
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.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120124/80c54192/attachment-0001.asc>