Re: A new spin on multihoming: multihoming classes.

[smd@ebone.net (Sean Doran)]

Geoff -

| At 9/6/01 04:00 AM, Sean Doran wrote:
| >I think we would like to solve the problems for ANY site
|
| The more general issue of multi-homed networks when you include both 
| transit and stub domains may require somewhat different approaches to solve.

Well, I think you are just agreeing with me, of course. :-)

I did specifically say "site" and not network.  For clarity, this means
we are in apparent agreement, as "site" != [transit] "provider" / "network".

Multi6 is chartered to solve site multihoming, not all multihoming.
If what is produced solves all multihoming, I don't think anybody 
would complain.  On the other hand, we should not get bogged down
into refusing various approaches to site multihoming just because
we (maybe) don't know how to make "the stuff in the middle" 
deal well/properly/adequately/at all (choose one) with "its own" 
topological complexity.

That said, I don't think it is impossible to predict that a given
approach to site multihoming will operate with a vast array of
possible solutions to THAT problem, and I think most of the
options being discussed on the list are pretty open to lots
of "weird core stuff".

Please yelp if you disagree.

	Sean.