Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)
Iljitsch van Beijnum
iljitsch at muada.com
Thu Mar 2 13:22:04 UTC 2006
On 2-mrt-2006, at 13:44, william(at)elan.net wrote:
>> 2. In my current thinking on how to achieve ASN based IDR, we
>> would not need ASNs for every organization that multihomes,
>> only for each organization that provides transit. This
>> would greatly reduce some of the current and future demand
>> for ASNs.
Yes, we wouldn't want to run out of AS numbers just now we're
creating 4.29 billion new ones...
> 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.
> 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.
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.
More information about the NANOG
mailing list