Multihoming - Resilience or Independence
Hiya All, There has recently been a long thread, getting rather technical, about how best to achieve multihoming with the best resilience, etc. However, I feel there is another perhaps stronger argument as to why a customer wishes to obtain, keep and announce his own prefix(es): Bandwidth costs are reducing rapidly and customers do not wish to be tied to a single provider because of the pain associated with renumbering their address space. Going through the hoops to achieve multihoming may not improve resilience but, especially if they are "slow" setting up the second connection, the bandwidth can be cheaper as the customer can change ISPs much more easily if the price stays too high. It would be interesting to know which fraction of the "unclean" address space is singly connected. Our customer base may be unusual, but over 50% would not suprise me. Cheers Dave ps. Do not let any customers see this email..... :-)
Hi dave, hi all,
Hiya All,
There has recently been a long thread, getting rather technical, about how best to achieve multihoming with the best resilience, etc.
However, I feel there is another perhaps stronger argument as to why a customer wishes to obtain, keep and announce his own prefix(es):
there are a lot of reasons why customers want to be multi-homed. And what I'm seeing here is, that the ISP community is not able to offer such a service. But instead of blaming the "stupid" customers, ISP should go home and make their homework. -- Arnold
Hi, On Wed, Oct 10, 2001 at 12:04:23PM +0200, Nipper, Arnold wrote:
there are a lot of reasons why customers want to be multi-homed. And what I'm seeing here is, that the ISP community is not able to offer such a service. But instead of blaming the "stupid" customers, ISP should go home and make their homework.
So what should "their homework be", then? BGP has its limitations, and there are no other WAN routing protocols yet that *would* work with ever-increasing table size and topology complexity. You're taking the very easy way "stop complaining, it's all your own fault". Things like "ISP confederations, many ISPs using the same address space and multi-homing their customers among themselves" is something that might work, but are VERY problematic when this breaks apart. See what happened to Contrib.NET - lots of small routes from 194.77.* as a result of this. ... and if you make it "one organization", then you have exactly what my proposal for resiliency and stability is: multihome to different POPs of the same ISP. Which will be sufficient for most enterprise customers (that do not add address management and end customer issues into this), and it will be a lot less expensive on them and on the global network than doing "externally visible multihoming". 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
Hoi Gert,
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 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. The new mantra is: go home and do your homework -- Arnold
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, 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 Hofdcker 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
Hoi Gert,
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 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
----- Original Message ----- From: "Nipper, Arnold" <arnold@nipper.de> To: "Gert Doering" <gert@space.net> Cc: "Dave Pratt" <djp-ripe-lists@djp.net>; <lir-wg@ripe.net>; <routing-wg@ripe.net> Sent: Wednesday, October 10, 2001 11:52 AM Subject: Re: Multihoming - Resilience or Independence there
are other and more financial drawbacks with this approach.
One major problem is not being able to offer an SLA on the routing of the address space, apart from the fact it is yet another route in the global routing tables.
The new mantra is: go home and do your homework
The new mantra is: We have done our homework now you do yours ;)
-- Arnold
Stephen meinte:
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.
One major problem is not being able to offer an SLA on the routing of the address space, apart from the fact it is yet another route in the global routing tables.
I can't see why you can't have SLAs. And which SLA exactly are you talking about? Of course another prefix and another AS is added to the routing table but thereby you are witdrawing at least more than two (both prefs as well as AS). ==> table gets smaller.
The new mantra is: go home and do your homework
The new mantra is: We have done our homework now you do yours ;)
motd (mantra of the day): re-do your homework. It was not good. -- Arnold
On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote:
Stephen meinte:
One major problem is not being able to offer an SLA on the routing of the address space, apart from the fact it is yet another route in the global routing tables.
I can't see why you can't have SLAs. And which SLA exactly are you talking about?
[...]
motd (mantra of the day): re-do your homework. It was not good.
Read again. Stephen wrote "SLA on the routing of the address space". Global routing of anyone's address space is dependent on the routing policies of individual (third-party) ISPs. Some may be your direct peers and you can have agreements with them; many others won't and there's no way you can guarantee they'll route your customer's address space. The larger the prefix, the larger the chance of some network operator out there filtering it to oblivion. Cheers, Steven
Read again. Stephen wrote "SLA on the routing of the address space". Global routing of anyone's address space is dependent on the routing policies of individual (third-party) ISPs. Some may be your direct peers and you can have agreements with them; many others won't and there's no way you can guarantee they'll route your customer's address space. The larger the prefix, the larger the chance of some network operator out there filtering it to oblivion.
read again: the idea is to put all multi-homing customers in one region into one prefix (ideally) (MH-pref) and one AS. The prefix should be large enough to guarantee worldwide routing. E.g. for DE you might have three or four of these clusters (or maybe only one). All ISP supporting this cluster are announceing this MH-pref. Internally of course you need a higher resolution. But that's not the problem. By covering the whole world with these MH-clusters you obtain 100 (maybe 200, maybe 1000) clusters. So BGP tablesize would be something of current #ISP + 1000 (or even 10000). Of course there are still a lot of problems. Mainly cashwise as ISP A could have to route traffic for customer X though he has no contract with customer X. And of course MH-AS look very messy. But ... -- Arnold
----- Original Message ----- From: "Nipper, Arnold" <arnold@nipper.de> To: "Steven Bakker" <steven@icoe.att.com> Cc: "Stephen Burley" <stephenb@uk.uu.net>; "Gert Doering" <gert@space.net>; "Dave Pratt" <djp-ripe-lists@djp.net>; <lir-wg@ripe.net>; <routing-wg@ripe.net> Sent: Wednesday, October 10, 2001 3:56 PM Subject: Re: Multihoming - Resilience or Independence
Read again. Stephen wrote "SLA on the routing of the address space". Global routing of anyone's address space is dependent on the routing policies of individual (third-party) ISPs. Some may be your direct peers and you can have agreements with them; many others won't and there's no way you can guarantee they'll route your customer's address space. The larger the prefix, the larger the chance of some network operator out there filtering it to oblivion.
read again: the idea is to put all multi-homing customers in one region into one prefix (ideally) (MH-pref) and one AS. The prefix should be large enough to guarantee worldwide routing.
Er you can not reserve space so you can not do this and if you give them enough space to garutee routing we are talking a /20 then that is LIR space size...hhmmm.
-- Arnold
Hi, On Wed, Oct 10, 2001 at 04:07:24PM +0100, Stephen Burley wrote:
Er you can not reserve space so you can not do this and if you give them enough space to garutee routing we are talking a /20 then that is LIR space size...hhmmm.
Back into MIR land :-) - but I think the main problem with this proposal is "what happens if the ISPs in question stop liking each other and this breaks apart" - which would not be the first time. 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
Hi,
On Wed, Oct 10, 2001 at 04:07:24PM +0100, Stephen Burley wrote:
Er you can not reserve space so you can not do this and if you give them enough space to garutee routing we are talking a /20 then that is LIR space size...hhmmm.
Back into MIR land :-) - but I think the main problem with this proposal is "what happens if the ISPs in question stop liking each other and this breaks apart" - which would not be the first time.
Yes but my proposal was within one company not spanning comapnies but if you go down the route suggested you are trying to resurect the Lastresort Registry and no one wants that....urgh.
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
Hi, On Wed, Oct 10, 2001 at 04:21:51PM +0100, Stephen Burley wrote:
Back into MIR land :-) - but I think the main problem with this proposal is "what happens if the ISPs in question stop liking each other and this breaks apart" - which would not be the first time.
Yes but my proposal was within one company not spanning comapnies but if you go down the route suggested you are trying to resurect the Lastresort Registry and no one wants that....urgh.
Definitely not. I was more thinking a long the route of "LIR confederations" (which APNIC had, as far as I know, and which didn't work). 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:
Hi,
On Wed, Oct 10, 2001 at 04:07:24PM +0100, Stephen Burley wrote:
Er you can not reserve space so you can not do this and if you give them enough space to garutee routing we are talking a /20 then that is LIR space size...hhmmm.
Back into MIR land :-) - but I think the main problem with this proposal is "what happens if the ISPs in question stop liking each other and this breaks apart" - which would not be the first time.
Money is always the best string that things don't fail. E.g.: MIRs could be organized/overseen by IXP. Each ISP wanting to contribute to MIR has to have a contract with the organisation running the MIR. And high penalties guarantee that the MIR is still there even "if the ISPs in question stop liking each other". Obviously the big advantage is that this model scales very well. -- Arnold
A little bit OT: I notify that the order of distribution is more or less randomly. Anyone else noticed this as well? IMHO it's quite contraproductive for discussions ... Examples: sent 2001/10/10 17:24 recv 2001/10/11 09:57 sent 2001/10/10 19:09 recv 2001/10/11 10:03 sent 2001/10/10 17:43 recv 2001/10/11 18:08 -- Arnold
Hiya Arnold, This is well known in some circles. Posts to the list are manually approved by the RIPE NCC to reduce spam, unless you send the message from an account which is subscribed (to that individual list I believe). That is why my messages have the sender djp-ripe-lists@djp.net, because that is the address under which I am subscribed and my messages appear almost immediately :) Cheers Dave Normally, djp@djp.net BT Ignite GmbH On Thu, 11 Oct 2001, Nipper, Arnold wrote: ->A little bit OT: I notify that the order of distribution is more or less ->randomly. Anyone else noticed this as well? IMHO it's quite contraproductive ->for discussions ... -> ->Examples: -> ->sent 2001/10/10 17:24 recv 2001/10/11 09:57 ->sent 2001/10/10 19:09 recv 2001/10/11 10:03 ->sent 2001/10/10 17:43 recv 2001/10/11 18:08 -> -> ->-- Arnold ->
space. The larger the prefix, the larger the chance of some network operator out there filtering it to oblivion.
Sorry to be picky, but I am sure you meant either 'the longer the prefix' or 'the smaller the prefix' ? Peter
On Wed, 2001-10-10 at 17:34, Peter Galbavy wrote:
space. The larger the prefix, the larger the chance of some network operator out there filtering it to oblivion.
Sorry to be picky, but I am sure you meant either 'the longer the prefix' or 'the smaller the prefix' ?
Sorry, yes, longer prefix, i.e., "more specific". Steven
On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote:
Of course another prefix and another AS is added to the routing table but thereby you are witdrawing at least more than two (both prefs as well as AS). ==> table gets smaller.
Your math is confusing... or maybe I'm misunderstanding the obvious. Yes, multihoming adds another AS and (at least one) (longish) prefix to the routing table. But in your reasoning, which two prefixes and one AS are being withdrawn? If I resiliently multi-home to one ISP, and I get my address space from its block, I do not add any prefix or AS to the (global) routing table. Even if I multi-home to two ISPs and selectively NAT depending on the outgoing connection, I'll be NAT-ing into the respective ISP's address space (which I presume is properly aggregated), adding no prefix or AS. Cheers, Steven
Hi All, On Wednesday 10 October 2001 11:52, Nipper, Arnold wrote:
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.
The new mantra is: go home and do your homework
I agreed with Arnold, that networks should be able to muli-home without the feeling that they are breaking the Internet. Of course that is sadly the case today. So, as per Arnold's suggestion, I did some homework on an alternative solution, basically to IPv6. This is only the first thoughts, just to get the main points across. Its is far from complete! If you can spare the time, wander to, http://logic.org.uk/ip-1.0.txt and see what you think. Regards, aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/
In message <20011010124248.Z16960@Space.Net>, Gert Doering writes:
Hi,
On Wed, Oct 10, 2001 at 12:04:23PM +0200, Nipper, Arnold wrote:
there are a lot of reasons why customers want to be multi-homed. And what I'm seeing here is, that the ISP community is not able to offer such a service. But instead of blaming the "stupid" customers, ISP should go home and make their homework.
So what should "their homework be", then? BGP has its limitations, and there are no other WAN routing protocols yet that *would* work with ever-increasing table size and topology complexity.
I have been monitoring IPv6 for exactly this point: how do IPv6 propose to give people redundancy/ressilience. So far I have not seen anybody really say "this is how it should be done". The best I have been able to gather is that it is expected that end customers assign multiple IP# to their servers and leave the selection to the DNS and the other end. I don't know if the "anycast" idea was part of this solution but right now I certainly don't see any other solution than DNS. My current advice to my customers are therefore: Multiple IP# per server, use DNS for load-balancing. I certainly think that in europe BGP-confederations can be a partial interrim solution, I can't see why we shouldn't be able to make one centered on the local IX'es for instance, but it would take actual will and interest from the local ISPs, and that would require market-demand... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Poul-Henning Kamp;
I have been monitoring IPv6 for exactly this point: how do IPv6 propose to give people redundancy/ressilience.
So far I have not seen anybody really say "this is how it should be done".
draft-ohta-e2e-multihoming-00.txt is dated April 2000. And, now, there even is a multi6 WG of IETF.
The best I have been able to gather is that it is expected that end customers assign multiple IP# to their servers and leave the selection to the DNS and the other end. I don't know if the "anycast" idea was part of this solution but right now I certainly don't see any other solution than DNS.
My current advice to my customers are therefore: Multiple IP# per server, use DNS for load-balancing.
The problem is that load-balancing is not a reason for multi-homing. With the same amount of payment, you should be able to get more bandwidth from a single ISP (bulk discount) than from multiple ISPs that there is no need for load-balancing. Masataka Ohta
In message <200110102043.FAA26347@necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites:
So far I have not seen anybody really say "this is how it should be done".
draft-ohta-e2e-multihoming-00.txt
is dated April 2000.
And, according to IETF rules, because of its age: obsolete ?
And, now, there even is a multi6 WG of IETF.
Cool, lets see what they can disagree on in a couple of years...
My current advice to my customers are therefore: Multiple IP# per server, use DNS for load-balancing.
The problem is that load-balancing is not a reason for multi-homing.
(For the moment, you can save yourself a lot of time by assuming that I actually know what I'm talking about :-) Load-balancing means different things to different people... Some people include in "load-balancing" the ability to disable non-responsive servers, upstream providers and so on. Just as we learned that checksums and handshakes only matter if they are end-to-end, the same way people will eventually realize that load-balancing, redundancy and resillience only matter if implemented end-to-end. But that doesn't change the fact that people will still want a solution now, that neither "go to IPv6" nor "wait for IPv6" will satisfy them and that ISP's who are able to meet this demand will make more money than ISP's who can't... Human nature being what it is, we can also pressume that rules will be bent as far as possible and that more money speaks louder... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Poul-Henning Kamp;
draft-ohta-e2e-multihoming-00.txt
is dated April 2000.
And, according to IETF rules, because of its age: obsolete ?
Current most one is of version 02.
draft-ohta-e2e-multihoming-00.txt
And, now, there even is a multi6 WG of IETF.
Cool, lets see what they can disagree on in a couple of years...
IETF process is so quick that you can see it already. :-)
Load-balancing means different things to different people...
So is multihoming.
But that doesn't change the fact that people will still want a solution now, that neither "go to IPv6" nor "wait for IPv6" will satisfy them and that ISP's who are able to meet this demand will make more money than ISP's who can't...
Huh? It's you who asked about IPv6. Anyway, I think we will use up IPv4 address space before IPv4-style multihoming kills the backbone. It will happen within 3 years. A good news is that, not wating multi6 WG conclude, end-to-end multihoming will be implemented this year and used for commercial service (IPv4 service will, of course, continue) thanks to funding from Japanese Goverment. Masataka Ohta
In message <200110102151.GAA26904@necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites:
But that doesn't change the fact that people will still want a solution now, that neither "go to IPv6" nor "wait for IPv6" will satisfy them and that ISP's who are able to meet this demand will make more money than ISP's who can't...
Huh? It's you who asked about IPv6.
No, I didn't ask, I pointed out that there were _still_ neither an established technique nor a policy for IPv6 in this area.
Anyway, I think we will use up IPv4 address space before IPv4-style multihoming kills the backbone. It will happen within 3 years.
I think you will see a lot of IPv4 space reclaimed by force will be able to put IPv4 on life-support for a LONG time... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
On Wednesday 10 October 2001, at 12 h 4, "Nipper, Arnold" <arnold@nipper.de> wrote:
there are a lot of reasons why customers want to be multi-homed. And what I'm seeing here is, that the ISP community is not able to offer such a service. But instead of blaming the "stupid" customers, ISP should go home and make their homework.
Or, said in an other way: RIPE policies make very difficult to be multihomed, therefore people in RIPEland take a lot of time to explain that multihoming is bad.
On Thu, 11 Oct 2001, Stephane Bortzmeyer wrote:
Or, said in an other way: RIPE policies make very difficult to be multihomed, therefore people in RIPEland take a lot of time to explain that multihoming is bad.
RIPE doesn't make up the policies - the members make the policies. RIPE didn't invent IP either, nor did they have a say in the design of router architecture, nor in the pricing of RAM chips. Multihoming which relies on long prefixes being carried in the default free zone, and/or more AS numbers, simply doesn't scale. That isn't a policy matter, it's simple math. Which policy do you think should be changed in order to "solve" the multihoming problem? Aled -- QiX Limited
RIPE doesn't make up the policies - the members make the policies.
Member involvement in RIPE is the same as with most 'standards' bodies. A very small %age of the membership understand the weird (acadaemia originated) processes and the beaurocrary required to be involved. Most members just want a service... Peter
All, A clarification: The policies implemented by the RIPE NCC are set by the Internet community (i.e the RIPE community). The RIPE community is open to everyone who is interested in the workings of the Internet. The RIPE community has no formal membership and its activities are performed on a voluntary basis, except the activities performed by the RIPE NCC (http://www.ripe.net/ripencc/about/). You do not have to be a member of the RIPE NCC to suggest a change of policy or to raise an issue you think needs to be discussed. There are no complicated processes or steps involved to change policy. All you need to do is to post a mail to the relevant mailing list (for policy matters it is <lir-wg@ripe.net>) or to bring it up one of the working groups in a RIPE meeting. If, after some discussion in relevant working group, consensus is reached, then the RIPE NCC will implement this policy. Kind regards, Nurani Nimpuno RIPE NCC At 15/10/01 09:30 +0100, Peter Galbavy wrote:
RIPE doesn't make up the policies - the members make the policies.
Member involvement in RIPE is the same as with most 'standards' bodies. A very small %age of the membership understand the weird (acadaemia originated) processes and the beaurocrary required to be involved. Most members just want a service...
Peter
participants (24)
-
Adrian Bool -
Aled Morris -
Carl Moberg -
Dave Pratt -
Gert Doering -
Hamid Alipour -
Havard Eidnes -
Jan-Ahrent Czmok -
Jan-Ahrent-Czmok -
Kurt Erik Lindqvist KPNQwest -
Lars Marowsky-Bree -
Marc Williams -
Masataka Ohta -
Niall Richard Murphy -
Nipper, Arnold -
Nipper, Arnold -
Nurani Nimpuno -
Peter Galbavy -
Poul-Henning Kamp -
Randy Bush -
Sabri Berisha -
Stephane Bortzmeyer -
Stephen Burley -
Steven Bakker