nanog mailing list archives
Re: Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)
From: "william(at)elan.net" <william () elan net>
Date: Thu, 2 Mar 2006 09:55:17 -0800 (PST)
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 --- DIf 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 thataggregate 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
Current thread:
- Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing], (continued)
- Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing] Per Heldal (Mar 06)
- Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing] Kurt Erik Lindqvist (Mar 06)
- Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing] Per Heldal (Mar 07)
- Re: Shim6 vs PI addressing Jeroen Massar (Mar 02)
- Re: Shim6 vs PI addressing Owen DeLong (Mar 02)
- Re: Shim6 vs PI addressing Jeroen Massar (Mar 02)
- Re: Shim6 vs PI addressing Owen DeLong (Mar 02)
- Re: Shim6 vs PI addressing Mark Newton (Mar 02)
- Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing) william(at)elan.net (Mar 02)
- Re: Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing) Iljitsch van Beijnum (Mar 02)
- Re: Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing) william(at)elan.net (Mar 02)
- Re: Shim6 vs PI addressing Jared Mauch (Mar 01)
- Re: Shim6 vs PI addressing Owen DeLong (Mar 01)
- Re: Shim6 vs PI addressing Jared Mauch (Mar 02)
- Re: Shim6 vs PI addressing Owen DeLong (Mar 02)
- Re: Shim6 vs PI addressing David Barak (Mar 02)
- Re: Shim6 vs PI addressing Iljitsch van Beijnum (Mar 01)
- Re: Shim6 vs PI addressing David Barak (Mar 01)
- Re: Shim6 vs PI addressing Todd Vierling (Mar 03)
- Re: Shim6 vs PI addressing Stephen Sprunk (Mar 03)
- Re: Shim6 vs PI addressing Stephen Sprunk (Mar 03)