Re: A new spin on multihoming: multihoming classes.

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Sun, 9 Sep 2001, Peter Tattam wrote:

> At issue is a big question as to whether BGP will scale *across the whole
> network* . I haven't seen a clear informed answer to this yet.   Many of the
> studies I've seen refer only to empirical studies and analysis of the current
> v4 network and predictions of what is likely in the next year or so.

Even if we assume the stability of new multihomers is the same of that of
current networks, the load on the BGP route processing system will
increase faster than the number of routes because each update needs to be
done on a larger table. This means order O(x^2) if doing an update scales
in a linear way or O(x log x) if it scales logarithmically.

> Finally I might add that I have to concede there is one fundamental flaw in the
> host based or DNS based solutions to MH and that was eloquently pointed out by
> someone else.  DNS needs routing so routing can't depend on DNS which means we
> can't use it as it is currently implemented, primarily because DNS is agnostic
> towards routing conditions.

Eloquent, but wrong. In the multi-address multihoming (MAMH) proposals
we've seen lately, there are never changes to single homed routing. So as
long as the domain name system only depends on single homed routing, there
is no problem. Also, no actual forwarding decisions depend on DNS
information, it is only used to find out addresses associated with a
hostname (or possibly with another address). This is hardly a new thing
for the DNS.

If we're going to do MAMH, we need three things:

1. initial address discovery: DNS already does this
2. address negotiation: mobile IP already does this
3. failover: this we don't have

Not a strict requirement, but it would be very helpful to have a choice
whether the end hosts or a proxy/router/NAT-like box does the necessary
multi-address multihoming processing.

> This implies that you need a globally reachable sub system that is independent
> of MH conditions which will then supply the MH information for any site based
> or transport based MH solutions to function.   Very likely it could borrow
> heavily from DSN, but it would need to be redesigned to be resilient to MH
> conditions which I believe DNS is not.

In the DNS, the information for each zone is replicated over two or more
servers. Rather than making sure you can always get at a certain server,
the DNS makes sure you can always get at the information by trying servers
until a live one is found. If all TCP/IP applications (well, the DNS is
not really an "application") did this, there would be no need for
multihoming support.

> An idea springs to mind - why not have an alternative system based on BGP
> *independent* of the routing system from which reachability information can be
> gathered.  Such a BGP system would need to be extended so that whole DFZ would
> not need to be kept in the BGP server, but rather the localized routing needs
> of the site instead, much in the same way that a DNS server only keeps the
> localized name mapping that it requires for the sites current connections.

In BGP, all the routers in the path need to know a route. Since that can't
be a requirement here (back to BGP scaling) we're limited to multi-address
multihoming or tunneling/rewriting schemes.

So I would send a query along the lines of "what are all of the addresses
for a:b:c:d::1/128 and how reachable are they" to a root reachability
server. That one would probably return "a:b::1:2:3 is authorative for
a:b::/32" and assuming no more recursion a:b::1:2:3 would answer:

"alternative prefixes for a:b:c:d::/64 are:
a:b:c:d:: min RTT: 1700 us, bandwidth 1544 kbps, reliability 100%
d:e:f:9:: min RTT: 520 ms, bandwidth 44736 kbps, reliability 99%
5:6:7:8:: min RTT: 20 ms, bandwidth 128 kbps, reliability 93%
additional information:
d:e:f:9::1/128 reliability 0%"

meaning the site is connected over a T1, a satellite DS3 and ISDN dial-up,
and the host in question not being able to use the ISDN line at the
moment.

Iljitsch van Beijnum