Multihoming - Resilience or Independence

It is odd that I have to agree with you on "customer do need multiple links
to different ISPs" but I hope it is not because CW carries other ISP's
non-CIDRable prefixes to let you think "CW less" about us.

The point is we will aggregate other ISP's prefixes if they are CIDR able.
Most of the case
are there are holes in the range so CIDR is out-of-question.

While the other camp insist to filter out any routes more specific than /20.
They are doing nothing to re-allocate their PA assigned to multi-homed
customers so CW can CIDR them into /20.

The funny thing is the solution are controlled by the other camp but they
are all talk but
no action. (Or trying to tell you multi-homed is a bad idea because they
can't deal with the
routing table ).

Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net


> -----Original Message-----
> From: Peter Galbavy [mailto:peter.galbavy at knowtion.net]
> Sent: Thursday, October 11, 2001 4:17 AM
> To: Kurt Erik Lindqvist KPNQwest; Nipper, Arnold
> Cc: lir-wg at ripe.net; routing-wg at ripe.net
> Subject: Re: Multihoming - Resilience or Independence
> 
> 
> > > the basic issue is that multi-homing is *the demand*. And 
> it's not the
> ISP
> > > who has to evaluate whether it's the right one but the 
> *customer*. We
> live
> > > in a customer - driven world. Money makes the world go round, not
> techies.
> >
> > Is that really what the customer want? Or do they actually 
> want resilience
> > and redundancy? And for that there are other ways...
> 
> I have been watching this thread for a while now, and I 
> finally cannot help
> but stick my oar in.
> 
> There are two very clearly defined camps here; one the 
> 'technical' camp that
> says 'we have many ways of making it work' or 'this is the 
> only way it will
> work' and the other camp is the 'commercial' saying either 
> 'the customer
> does not trust just one ISP' or 'I don't care how it works, 
> but it must
> work'.
> 
> Now, to add just another opinion to the thread, which is 
> really not that
> different to some other but may possibly offer something new;
> 
> In my line of work I have set-up 4 LIRs in the past two years 
> for companies
> that have had either had bad experiences with their ISPs 
> (usually more than
> one serially) or some have had to do all 'reasonable' things 
> to ensure good,
> reliable connectivity for either contractual or due-diligence reasons.
> 
> Regardless of how good an ISP is *now*, there will come a 
> time when they are
> sold, bought, merge or go bust that causes change. My 
> personal bugbear was
> INS. Great in the early days, but within days of 
> Clueless&Witless buying
> them, the whole thing started to come apart. This is not 
> isolated, and they
> are not the only ones at all.
> 
> Also, especially in Europe, ISPs tend to be reliant on 3rd 
> party local-loop
> carriers, even when we are talking about data-centre / 
> co-location delivery
> of services. In the UK, all ISPs exclude 3rd party links from 
> SLAs. Right.
> Good one.
> 
> Trying to solve the problem of people not trusting ISPs by 
> changing the
> technology to ensure that people *must* trust one ISP (IPv6 
> IMHO is just
> such a technology) is not a very customer friendly attitude. 
> It does not
> work and will not work.
> 
> In every other line of business, it is quite normal to buy 
> your product or
> service from two suppliers, telecoms and Internet are the only real
> exceptions. You could also discount other utilities, but 
> there is an issue
> of delivery there that precludes efficient and real 
> competition, so no more
> there please. As the Internet becomes a true necessity for 
> business, supply
> will more and more be selected like any other service, and the same
> contingencies will be made.
> 
> So, IMHO, please stop trying to 'solve' the problem by 
> pretending that you
> or any other ISP is reliable, civil and economically viable 
> and stop trying
> to 'solve' the problem by mandating technology solutions that 
> enforce this
> goal. It will not work.
> 
> Peter
> 
> 
>