Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)
william at elan.net
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
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 at elan.net
More information about the NANOG