Re: Multihoming - Resilience or Independence
Hi, On Wed, Oct 10, 2001 at 12:52:37PM +0200, Nipper, Arnold wrote:
You're taking the very easy way "stop complaining, it's all your own fault".
Maybe it's easy, but I must say I've seen megatons of complaints, rants, ... but not yet a kilo of an idea how to solve the problem.
I have provided a number of suggestions. Multiple times. The basic issue is that multihoming is not *the* answer. It's *one*, and it has to be evaluated whether it's the right one for any specific customer. Besides things caused by multihoming, there are many other prefixes that are announced but could be avoided by better aggregation or renumbering.
I still can't see why the idea of having own netblocks and AS for multi-homing customers breaks if one ISP is going south. But of course there are other and more financial drawbacks with this approach.
Not "going south". But "leaving the confederation due to unsolvable political problems". See what happened with Contrib.NET when they broke into GTN and TCP/IP (to repeat myself). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert,
The basic issue is that multihoming is not *the* answer. It's *one*, and it has to be evaluated whether it's the right one for any specific customer.
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. Go home and make your homework. -- Arnold
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.
Im going to stick a pile of money on my desk and ask it to configure this router for me. -- Marc
On 2001-10-10T13:14:23, "Nipper, Arnold" <arnold@nipper.de> said:
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.
Go home and make your homework.
That attitude is partly the problem for the current situation on the backbone. You see, if a solution just won't work, there is no point in selling it to the customer; you are not living in a customer-driven world, but in a world driven by the fastest access to his money. Anyway, this is seriously offtopic here and I would suggest that you go back home and make your _own_ homework first. -- "I'm extraordinarily patient provided I get my own way in the end." -- Margeret Thatcher
At 01:14 PM 10/10/2001 +0200, you wrote:
Gert,
The basic issue is that multihoming is not *the* answer. It's *one*, and it has to be evaluated whether it's the right one for any specific customer.
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.
- "I would like a car made out of wood." - "I don't think that that is a good..." - "Stop being a techie, give me a car made out of wood."
Go home and make your homework.
...and you could hear the customers router-"guru" on the verge of crying because he has *no* idea how to get out of this mess he's in from flapping his bgp-session ("umm a couple of times, no idea how many"), and where ever did his routers config go ("It was right here, honest")?
-- Arnold
-- carl
Hi, On Wed, Oct 10, 2001 at 01:14:23PM +0200, Nipper, Arnold wrote:
The basic issue is that multihoming is not *the* answer. It's *one*, and it has to be evaluated whether it's the right one for any specific customer.
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.
Which is part of the problem, yes. But as a responsible ISP, it *is* our job to recommend to our customers the best thing for them, and for the network in general. Nobody is served if we all try to make as much money as possible this year, just to see the basic infrastructure become unusable in a year or two. Randy says the IRTF needs about 5 years to come up with a new routing paradigm, so it's our job to make sure what we have lasts until then.
Go home and make your homework.
Why don't you keep out of this discussion if you don't want to contribute? Besides, I *am* making my homework. I point fingers at problems that some persons claim do not exist. I point out possible (but inconvenient) solutions. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert meinte:
Randy says the IRTF needs about 5 years to come up with a new routing paradigm, so it's our job to make sure what we have lasts until then.
If we can go for another five years, go on. If not than there has to be a solution earlier. It's almost unbelievable but obviously no one was thinking about this problem when we ran into the IPv4 debacle and invented IPv6. So hurry up.
Go home and make your homework.
Why don't you keep out of this discussion if you don't want to contribute?
Luckily it's not you who decides who contributes or not. -- Arnold
Hi Arnold,
The basic issue is that multihoming is not *the* answer. It's *one*, and it has to be evaluated whether it's the right one for any specific customer.
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... - kurtis -
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
On Thu, Oct 11, 2001 at 09:16:41AM +0100, Peter Galbavy wrote: Hi Peter,
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.
Not that I know anything, but in my opinion, you are inaccurate in two respects here. Firstly, IPv6 *technology* is not the issue. You can do everything that you could do in IPv4 with IPv6, and this includes the current methodology for multihoming. It also introduces another way of multihoming, which is akin to taking PA space from multiple upstreams and initiating/receiving connections according to some well defined algorithms. I don't think there is any case to be made that the technology forces a user to trust one ISP. Secondly, however, it has been in my limited experience IPv6 *policy* which has been perhaps more restrictive, inflexible and badly defined than necessary, and in particular address allocation policy. Thankfully this is well on the way to being changed, particularly after the developments of the last RIPE meeting. If you are interested, you should contribute; that way we all benefit from your insights. Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/
Just a short comment from the RIR perspective. The issues brought up in this discussion are questions that the RIPE NCC hostmasters are confronted with daily in the IP request handling. Requesters who wish to multi-home (for one reason or the other) often ask the hostmasters for advise on whether to do it with PI address space or by having their upstream announcing a more specific route within a PA aggregate (which is then also separately announced through a second upstream). Rather than the RIRs giving advise on these operational matters, we think it would be appropriate and helpful if these recommendations would come from the ISP community. A few BCPs or guideline documents would be useful to point these requesters to. Could this be an initiative for the routing-wg? Kind regards, Nurani Nimpuno RIPE NCC At 11/10/01 13:50 +0100, Niall Richard Murphy wrote:
On Thu, Oct 11, 2001 at 09:16:41AM +0100, Peter Galbavy wrote:
Hi Peter,
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.
Not that I know anything, but in my opinion, you are inaccurate in two respects here.
Firstly, IPv6 *technology* is not the issue. You can do everything that you could do in IPv4 with IPv6, and this includes the current methodology for multihoming. It also introduces another way of multihoming, which is akin to taking PA space from multiple upstreams and initiating/receiving connections according to some well defined algorithms.
I don't think there is any case to be made that the technology forces a user to trust one ISP.
Secondly, however, it has been in my limited experience IPv6 *policy* which has been perhaps more restrictive, inflexible and badly defined than necessary, and in particular address allocation policy. Thankfully this is well on the way to being changed, particularly after the developments of the last RIPE meeting. If you are interested, you should contribute; that way we all benefit from your insights.
Niall
-- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/
Hi, On Thu, Oct 11, 2001 at 05:34:10PM +0200, Nurani Nimpuno wrote:
A few BCPs or guideline documents would be useful to point these requesters to. Could this be an initiative for the routing-wg?
I agree that such BCP documents would be very useful. The tricky thing is to agree on what "best" means in that context, as everybody seems to disagree on what they think should be the goal... Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
----- Original Message ----- From: "Gert Doering" <gert@space.net> To: "Nurani Nimpuno" <nurani@ripe.net> Cc: <lir-wg@ripe.net>; <routing-wg@ripe.net> Sent: Thursday, October 11, 2001 5:13 PM Subject: Re: Multihoming - Resilience or Independence
Hi,
On Thu, Oct 11, 2001 at 05:34:10PM +0200, Nurani Nimpuno wrote:
A few BCPs or guideline documents would be useful to point these requesters to. Could this be an initiative for the routing-wg?
I agree that such BCP documents would be very useful.
The tricky thing is to agree on what "best" means in that context, as everybody seems to disagree on what they think should be the goal...
BCP does not mean that you only have to propose one solution. -- Arnold
On Thu, Oct 11, 2001 at 05:34:10PM +0200, Nurani Nimpuno wrote:
Just a short comment from the RIR perspective.
The issues brought up in this discussion are questions that the RIPE NCC hostmasters are confronted with daily in the IP request handling.
Requesters who wish to multi-home (for one reason or the other) often ask the hostmasters for advise on whether to do it with PI address space or by having their upstream announcing a more specific route within a PA aggregate (which is then also separately announced through a second upstream).
Rather than the RIRs giving advise on these operational matters, we think it would be appropriate and helpful if these recommendations would come from the ISP community.
A few BCPs or guideline documents would be useful to point these requesters to.
Do you know somebody from other RIRs who has been working on these issues? Do you know somebody from other RIRs who already have done these issues? Do you think that this technology acceptance will be reached without changes to other BCPs or guideline documents?
Could this be an initiative for the routing-wg?
I think it would be nice.
Kind regards,
Nurani Nimpuno RIPE NCC
-- Regards, Vladimir.
On Thu, 11 Oct 2001 17:34:10 +0200 Nurani Nimpuno <nurani@ripe.net> wrote:
Just a short comment from the RIR perspective.
The issues brought up in this discussion are questions that the RIPE NCC hostmasters are confronted with daily in the IP request handling.
Requesters who wish to multi-home (for one reason or the other) often ask the hostmasters for advise on whether to do it with PI address space or by having their upstream announcing a more specific route within a PA aggregate (which is then also separately announced through a second upstream).
Rather than the RIRs giving advise on these operational matters, we think it would be appropriate and helpful if these recommendations would come from the ISP community.
A few BCPs or guideline documents would be useful to point these requesters to. Could this be an initiative for the routing-wg?
Kind regards,
Nurani Nimpuno RIPE NCC
Hi Nuriani, hi lir-wg, hi routing-wg, i am starting to write a BCP / guideline document covering this issue. I would appreciate the help of other network operators, since i do not know all network operators directly. The version(s) of the document can be accessed at www.lambda-solutions.de/bcp/ I already did a first draft covering the items which will be in the document but would appreciate if i could get help from the different operators. I would like to have input from the current practice from: - Level3 - UUnet - Sprint - C&W - Ebone (which i would declare as "major transit provider" because i don't like the terminology about "tier-xyz") and also from the other important downstream isps, how they handle this issues. Also some information from ripe would be handy, if they ACK issue PA assignments or do PI requests for this kind of issue. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
On Thu, 11 Oct 2001 17:34:10 +0200 Nurani Nimpuno <nurani@ripe.net> wrote:
Just a short comment from the RIR perspective.
The issues brought up in this discussion are questions that the RIPE NCC hostmasters are confronted with daily in the IP request handling.
Requesters who wish to multi-home (for one reason or the other) often ask the hostmasters for advise on whether to do it with PI address space or by having their upstream announcing a more specific route within a PA aggregate (which is then also separately announced through a second upstream).
Rather than the RIRs giving advise on these operational matters, we think it would be appropriate and helpful if these recommendations would come from the ISP community.
A few BCPs or guideline documents would be useful to point these requesters to. Could this be an initiative for the routing-wg?
Kind regards,
Nurani Nimpuno RIPE NCC
Hi Nuriani, hi lir-wg, hi routing-wg, i am starting to write a BCP / guideline document covering this issue. I would appreciate the help of other network operators, since i do not know all network operators directly. The version(s) of the document can be accessed at www.lambda-solutions.de/bcp/ I already did a first draft covering the items which will be in the document but would appreciate if i could get help from the different operators. I would like to have input from the current practice from: - Level3 - UUnet - Sprint - C&W - Ebone (which i would declare as "major transit provider" because i don't like the terminology about "tier-xyz") and also from the other important downstream isps, how they handle this issues. Also some information from ripe would be handy, if they ACK issue PA assignments or do PI requests for this kind of issue. --jan -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofï¿œcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404
A few BCPs or guideline documents would be useful to point these requesters to. Could this be an initiative for the routing-wg?
IMHO - yes. If we could come up with a common policy to handle these requests it would be better for all. - kurtis -
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.
not a problem. they can demand all they want. but i will listen to their flakey routes when they *pay* me to do so. randy
On Wed, 10 Oct 2001, Randy Bush wrote:
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.
not a problem. they can demand all they want. but i will listen to their flakey routes when they *pay* me to do so.
No flame intended here, but aren't your customers already paying you to get the best connectivity to remote sites? If a more specific route is shorter or has more bandwith available shouldn't you route the traffic that way in the interest of your customers? Of course I see the point in filling up 128megs of ram with routing tables but I ask myself what costs more; 128megs of extra ram or customers running off to another ISP because that has better connectivity to their favorite site? -- Sabri Berisha ~ my own opinions etc ~
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. not a problem. they can demand all they want. but i will listen to their flakey routes when they *pay* me to do so. No flame intended here, but aren't your customers already paying you to get the best connectivity to remote sites?
and part of that is running a reliable and stable network. i do kinda well at that. and part of it is routing stability. and part of that is not listening to rubbish. randy
On Wed, 10 Oct 2001, Randy Bush wrote:
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.
not a problem. they can demand all they want. but i will listen to their flakey routes when they *pay* me to do so.
No flame intended here, but aren't your customers already paying you to get the best connectivity to remote sites?
Presumably the customers also want this connectivity to be reasonably stable? If there is a conflict between "stable connectivity to most of the Internet" or "not quite so stable connectivity to everywhere", I think it's a no-brainer for an ISP to choose between the two. This in combination with a certain dose of defensive conservatism is what caused the birth of "route filtering on RIR allocation boundaries".
Of course I see the point in filling up 128megs of ram with routing tables but I ask myself what costs more; 128megs of extra ram or customers running off to another ISP because that has better connectivity to their favorite site?
As has been said in other venues many other times: it's not just the cost of the DRAM that's the issue here. Certain CPU boards or router systems typically have a maximum amount of memory which can be installed, and there's a certain "step function" associated with crossing that limit, and the price increase is quite a bit higher than the cost of an additional 128MB module. Secondly, trying to solve this problem by just throwing more memory at the problem is likely to expose other scalability problems caused by a large default-free routing table, such as excessive convergence times, CPU horsepower deficiencies to keep up with doing the route computation in the face of an increasing stream of routing updates etc. etc. etc. The real worry has however been that the growth in the default-free routing table has in the past exceeded the growth predicted by "Moore's law" (which in the past has reasonably well predicted the electronics component manufacturers' ability to produce faster or higher-density components, be that CPUs, DRAMs or what have you), which does not bode well for the longer-term success of the approach of "throwing hardware at the problem". So, it's some peoples' opinion that if this problem is going to be solved properly (in a properly scalable fashion), we probably need a new routing and addressing paradigm. It is my current personal opinion that in this context IPv6 doesn't really contribute anything up and above IPv4's routing architecture except "more of the same" (i.e. longer addresses, but still holding on to most other aspects of the IPv4 routing architecture). However, let's just say that I'm not holding my breath while waiting... Regards, - H�vard
would IP address defragmentation of Multi homed ISPs help to condense the BGP routing tables? two multi home ISPs with one prefix each will take the same routing table space as one multi homed ISP with two prefixes Regards, Hamid Alipour
participants (17)
-
Carl Moberg -
Gert Doering -
Hamid Alipour -
Havard Eidnes -
Jan-Ahrent Czmok -
Jan-Ahrent-Czmok -
Kurt Erik Lindqvist KPNQwest -
Lars Marowsky-Bree -
Marc Williams -
Niall Richard Murphy -
Nipper, Arnold -
Nipper, Arnold -
Nurani Nimpuno -
Peter Galbavy -
Randy Bush -
Sabri Berisha -
Vladimir A. Jakovenko