Stephen, >>> SHIM6, HIP, and multiple PA blocks were not, and are still not, >>> considered viable options; my understanding of this RRG was to come >>> up with something that the "un-stoppable force" would find acceptable >>> so that it could be redirected that way.
> Multiple PA blocks is slightly more attractive because it is (in theory) > incrementally deployable, but it requires that every time an upstream > link goes up or down, you have to renumber your entire network > (including DNS, DHCP, etc.), plus lose any open TCP sockets that were > bound to addresses in the block being removed. Compared to the mostly > external costs of PI, that's out as well. With some engineering work, I think that multiple PA blocks could become more interesting. Since a look time, we have assumed that routing protocols, including BGP, need to react quickly to link failures and advertise the failure of each link as it happens. For BGP, this behaviour is one of the reasons why the number of BGP updates is so large. During the last years, we've seen a change to the way networks react to link failures, at least from an intradomain routing viewpoint. In many MPLS networks, link are protected from failures by using bypass tunnels or other techniques and the routing protocol can react slowly to these failures knowing that the failure is protected. Similar solutions have been proposed to use IP tunnels to protect interdomain links from failures, see e.g. http://inl.info.ucl.ac.be/publications/achieving-sub-50-milliseconds-recover Consider a typical multihomed stub AS, connected to two different providers, P1 and P2: +--------+ +--------+ | P1 | | P2 | +--------+ +--------+ \\ // +----------------+ | Stub AS | +----------------+ With today's BGP, the stub has typically one prefix that is globally advertised. When the link between P1 and the stub fails, P1 will withdraw the stub's prefix so that all ASes on the Internet will be able to reach the stub via its second provider, P2. Instead, assume that the stub has two PA blocks : P1.stub and P2.stub. When the link between the stub and P1 fails, P1 will not advertise anything globally, but we need to make sure that P1.stub remains reachable. The paper above describes in details how this link can be protected by using a preestablished tunnel between the border router of P1 (on the P1-stub AS link) and the border router of the stub AS (on the P2-stub AS link). To establish this protection tunnel, we only need some small changes to BGP that are described in the detailed paper. This protection tunnel allows the packets towards P1.stub to reach the subAS even when the link between the stub AS and P1 fails. Such as solution could allow the utilisation of multiple PA blocks to be more acceptable by the network operators. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg