Re: A new spin on multihoming: multihoming classes.

[Daniel Senie <dts@senie.com>]

At 07:28 AM 9/9/01, Iljitsch van Beijnum wrote:
>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

4. a separate IP address prefix for each pipe from a site to the Internet, 
all of equal size.

This point seems to be missing from the discussion. While with IPv6 we like 
to think of sizing as infinite, we are busy dividing that space by 2 or 3 
to account for a large percentage of sites multihoming. That might be OK, 
or it might not.

This issue also raises some concerns in terms of whether the RIRs are 
willing to play along.

Clearly in an IPv4 world, assigning additional prefixes of equal size to a 
site is not going to go over well, and yet it's already an option, see below.


>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.

There are multi-ported NAT Boxes on the market today which provide a flavor 
of multihoming with IPv4. This approach, with one-to-one NAT, can provide 
some level of service today to make a site "multihomed" in an IPv4 world. 
Note, however, the consumption of address space.

So let's keep in mind that when we make the routing table in the DFZ small 
using host-based multihoming, we're having a significant effect on the 
amount of IP address space we're causing to be allocated.

This may be a tradeoff we're willing to make. I have not seen anyone 
mention it in the arguments made here, which concerns me. As a community 
and standards body, we have not always done a good job of considering 
future impacts of standards promoted.



> > 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.

And it would potentially take a LONG time to get connected to a web server, 
mail server, etc., if there were one or more dead machines on a list. Since 
it takes a while to get DNS changes propagated, that could continue for 
some time.


> > 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.

Are the DNS servers magically in a place where THEY are better connected? 
Arguably with this multi-connected site, the DNS servers could appear to be 
on separate networks, thus well protected. However, the time to find a 
responsive DNS server would have to be added to the other access times. 
Further the TTLs on the DNS data would need to be short, to reflect the 
changing nature of the data that you want to present. This can and is done 
today for load balancing, but the downside is excess DNS traffic and 
latency. Again, this may be a tradeoff we're willing to make. Let's just be 
sure we understand its effects on the whole.


>Iljitsch van Beijnum

-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com