[89086] in North American Network Operators' Group
Re: Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Thu Mar 2 08:22:37 2006
In-Reply-To: <Pine.LNX.4.62.0603020308550.25810@sokol.elan.net>
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>
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Thu, 2 Mar 2006 14:22:04 +0100
To: "william(at)elan.net" <william@elan.net>
Errors-To: owner-nanog@merit.edu
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.