Re: Transport level multihoming

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Wed, 8 Aug 2001, Greg Maxwell wrote:

> On Wed, 8 Aug 2001, Daniel Senie wrote:
> 
> > As I said, I remain open to transport level involvement if there's no other
> > way. The arguments REALLY do remind me of the 802.5 ones. While I agree we
> > are orders of magnitude larger in scope here, we also have significantly
> > improved technology to work with. The reliance on "sky is falling"
> > arguments to justify standards development which at best will take years is
> > what I'm questioning. MPLS was started because of a belief we could never
> > build routers that could handle the massive loads, yet routers CAN handle
> > the loads. Yes, MPLS has other uses now.
> 
> What would be useful is a metric for defining the global computational and
> storage complexity for transport-level and network-level multihoming.
> 
> Then we can make a comparison: Only if the global complexity of
> network-level solution is much less then the transport-level solution
> could it be an acceptable solution.
> 
> For example, if we accepted that people could only be multihomed to a
> single multi-provider (i.e. a provider maintains multiple separate but
> interconnected networks) so that we could maintain aggregation, this
> solution would be preferable on a global routing complexity basis to
> transport-level multihoming.
> 
It depends if the provider is supplying multiple completely independent paths
to the core or not.  If what you are implying is that a MH site can only have
multiple paths to its parent branch, or only partly up the tree to the core, 
this may be unnecessarily restrictive, and possibly defeat the purpose of
multihoming.

Peter

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210