Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)

Thu Mar 2 17:55:17 UTC 2006

On Thu, 2 Mar 2006, Iljitsch van Beijnum wrote:

>> My thinking was that its a big waste of memory (in the global bgp table) to 
>> announce every IPv6 route in full in particular for cases when its 
>> sub-allocation and aggregate is already being announced.
>
> Yes, it would be cool if the routers or route servers could automatically 
> detect this and clean up the routing table. Unfortunately:
>
>    A --- B
>  /         \
> X             Y
>  \         /
>    C --- D
>
> If X uses 172.16.1.0/24 but A also announces 172.16.0.0/12, then A or B could 
> decide to suppress the /24. However, Y will see the /24 through D and C but 
> not through B and A, so Y will now send all of its traffic to X through C and 
> D.

If you read through my design, it would be that Y should assume that
aggregate as seen from B is always valid path even if it is not directly 
indicated by inclusion of special subroute attribute. This maybe both
good and bad as far as such design goes.

>> But it maybe possible to do limited bgp multi-homing by having such /48 and 
>> similar routes included as attributes of the main route, i.e.
>>  A100:1000::/32 route would appear with extended attributes like
>>    Subroutes: 0010/16 (2)
>
> Some years ago, I suggested doing this by adding a bitmap to the aggregate 
> route: a single bit is enough to convey holes in the aggregate, with two or 
> three bits you can also do some traffic engineering. This will get you from a 
> /16 aggregate to individual /24s with 32 bytes (1 bit per more specific) or a 
> /32 to /48s with 8 kilobytes.

Can be done with bitmaps, but unless aggregate is very well filled with 
sub-allocations, this would be waste of memory too. I think individual 
subroutes is more reasonable as long as each one can be well compacted
(0010/16 is 16-bits for netblock, max 7 bits for netmask).

> Such an approach does depend on relatively tight packing of end-users that 
> share the same ISPs, though.
>
>> All these approaches (especially second one) however certain problems when
>> you have to consider route security & authorization (i.e. SIDR/SBGP space)
>
> IDR security doesn't come cheap anyway: be prepared to double or quadruple 
> your router's memory and install crypto hardware.

Yes, most likely it will require dedicated box to process the security 
data and verify ip routes (Note: in usual way dedicated box might be 
represented as being separate card in the router).

-- 
William Leibzon
Elan Networks
william at elan.net