[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A tunneling proposal



At 06:20 PM 7/16/01, Ramakrishna Gummadi wrote:
>One can think of a simple extension to tunneling under such ISP-wide
>outages---if tunnel creation fails, the second ISP initiates
>non-aggregatable route announcements for the prefixes from the address
>space of the first ISP who has become unreachable. This two step approach
>may prove effective for fixing both small-scale temporary and large-scale
>persistent problems.

This could work, provided the alternate upstream ISPs are willing, and 
other networks are willing to take the announcements. The concern is that 
RADB and similar are used by providers to restrict where announcements will 
come from. Keep in mind also that what we're talking about here is human 
intervention in the case of an outage. The question to be answered by 
prospective users of such a multhoming solution is how many hours of outage 
can be tolerated? I suspect it unlikely that automated tunnel creation and 
announcement setup would be well received by those running backbones, so 
there's likely to be a human element at play.


>It may be a good idea to examine a breakdown of the kind of failures
>experiences within an ISP, because this will help judge the effectiveness
>of the tunneling approach. But the primary motivation in tunneling is not
>to introduce unnecessray routes into the DFZ if there is an alternative.
>For example, I know that, in the context of server farms, about 20% of
>outages and errors are because of local power failures, but this may not
>hold in the ISP case. Does anyone have any info about the main problems
>and their frequencies?

Where's that 20% figure come from? With all the backups the colo vendor 
salesfolk talk about, that's a surprising figure.

While I understand the desire to find ways to avoid introducing routes into 
the DFZ, I firmly believe any solution should provide an automated 
resilience in the face of outages. I'm not yet convinced there's a good way 
to do this with tunnels.

>On Mon, 16 Jul 2001, Daniel Senie wrote:
>
> > At 05:40 PM 7/16/01, Ramakrishna Gummadi wrote:
> > >I hypothesize that the only scenario where tunneling for TCP
> > >and UDP fails is when the entire ISP is affected in a major way.
> >
> > Given economic conditions and the relative health or lack thereof of some
> > providers, this alone is a significant concern. If a network is powered
> > down by their bankers, customers who were multihomed via tunneling would be
> > out of luck. This isn't the type of redundancy that is going to make people
> > sleep well at night.
> >
> > People want to multihome so that any outage, from a local loop to a
> > backbone carrier can occur without obliterating their connectivity. I think
> > it important to keep that in mind.
> >
> > Tunneling is quite useful for fixing temporary problems, but I'm not
> > convinced it's a worthwhile solution to the multihoming problem.
> >
> > -----------------------------------------------------------------
> > Daniel Senie                                        dts@senie.com
> > Amaranth Networks Inc.                    http://www.amaranth.com
> >
> >
> >

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