[89102] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Notes on design of IPv6 BGP multihoming with special subroute

daemon@ATHENA.MIT.EDU (william(at)elan.net)
Thu Mar 2 12:56:17 2006

Date: Thu, 2 Mar 2006 09:55:17 -0800 (PST)
From: "william(at)elan.net" <william@elan.net>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: Owen DeLong <owen@delong.com>, Jeroen Massar <jeroen@unfix.org>,
	David Barak <thegameiam@yahoo.com>, Joe Abley <jabley@isc.org>,
	NANOG list <nanog@nanog.org>, Pekka Savola <pekkas@netcore.fi>
In-Reply-To: <ADFD26CC-58D4-455B-B28F-C8E076F3390A@muada.com>
Errors-To: owner-nanog@merit.edu



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@elan.net

home help back first fref pref prev next nref lref last post