[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Multiple PA blocks
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 rrg-request@psg.com 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