[ppml] Multihome Pro Con Document

[Michel Py]

Hi Jason,


> Jason Schiller wrote:
> I suspect this is exactly what Marla was trying to
> do in a non-negative constructive sort of way.

I don't doubt that a minute. I have done something similar a few years back (and did not listen then to the nay-sayers that said they tried before...). While I'm it, allow me to acknowledge the following as well:


> Howard, W. Lee wrote:
> Would it be fair, in your opinion, to distinguish three
> classes of network that might require multihoming?
> [..] It seems perfectly reasonable to have a host-based
> solution for end users, a feature-rich BGP for ISPs, and
> for enterprise networks to choose the solution that fits best.

Perfectly reasonable and fair yes. Good enough, no.



That being said,

> Jason Schiller wrote:
> It might be useful to explain why each of these solutions
> is not deployable for one or more types of multi-homing users.
> Adding this text may help to let people know how far off we
> are from a deployable solution.

> David Williamson wrote:
> Just to second this comment - this is probably the most
> productive thing anyone could contribute to this effort
> at this point. It's clear that the taxonomy of multi-homing
> users is unclear, so I'd stick to single examples of where
> each method won't work to get started.

I'm sorry to rain on the parade, but we have been through this process of taxonomy documents and requirement documents for a decade, inside and outside the IETF. I realize that some of you might not have followed it, but plenty of smart and well-connected engineers have put a considerable amount of work in this already. I regret to say that what I see today here is yet-another-occurrence of déjà-vu all over again.

A decade of failures to launch shows me that the process is flawed. Trying to think out of the box and stay positive, I offer the following two suggestions:

1. Think of a product, not a protocol. Instead of designing it then trying to figure out how to sell it, imagine something that looks hot in the eyes of the corporate IT manager and then figure it if you can make it work.

2. Replace BGP with a protocol that does not care about routing table bloat. Memory is cheap; the days that led to the "aggregated" IPv6 design when a 7500/RSP2/128 was the baddest core router one could buy are long gone. Today people are running dual full feeds on a 1800...

Michel.