RE: Multihoming by IP Layer Address Rewriting (MILAR)

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

On Thu, 6 Sep 2001, Michel Py wrote:

> >> "the subset of routers that do not receive a full routing table from
> >> a single peer or a default route".

> Or: "The subset of routers that do not use a default
> route, and peer with two or more other ASNs."

I want to exclude the routers that run defaultless by choice, rather than
out of necessity. You want to include those.

> If I have two BGP feeds from two major ISPs, why
> should I use a default route?

I can only tell you why I do it: the routers for "my" network don't have
enough memory to carry a full table. For two customers I have installed
filters to keep the routing table small(er) as well. They have Cisco 7500
routers with more than enough memory on the RSP, but only 32 MB on one of
the VIP cards. Those cards need a copy of the forwarding table and 32 MB
leaves to little room for error.

But if you can, it's better to take full routing from multiple
connections, because that way BGP can always find the shortest path.

> >>>> Definitely. I guess I have not made myself clear about the relation
> >>>> between MHTP and BGP. What should I change in 6.2.9 of
> >>>> http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt

The problem is that it is hard to find specific information I'm looking
for. MHTP rendevous points keep the mapping between multihomed addresses
and single homed addresses, right? But is this a static mapping or a
dynamic one?

I guess I'm used to the "inverted pyramid" writing style, which makes it
easier to glance at something and get the most important facts right away.

Back to the problem at hand. If we are going to translate addresses, we
need to know to things: what are possible valid addresses to translate to,
and which of the possible addresses are actually valid/reachable. Unless
I'm reading the draft wrong, you try to solve both in one go. I think
that's not the best solution, since this way a continuous stream of
reachability information flows around the globe, whether this information
is of use at a certain point at a certain moment or not. The mapping
between MH and SH addresses could easily be quite static if we employ
separate means to validate the SH addresses.

Also, using MH addresses that are reachable without translation makes
sense. That way, there is instant compatibility with non-MH-capable hosts
and it saves some processing and address space.

> >> Nameserver problem, can't get at the document right now. Maybe you should
> >> multihome...

[...]
> that makes my point about multihoming DNS servers I guess.

Disagree: the DNS system has its own redundancy features, which are even
better than multihoming. But many people still don't get it and put
primary and secondary nameservers in places with shared fate. I remember
one time that the entire berkeley.edu domain vanished. They had four
nameservers, but all on campus. It seems they have learned from this,
though.

Iljitsch