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
----- 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
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.
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
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 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
participants (11)
-
Adrian Bool -
Aled Morris -
Dave Pratt -
Gert Doering -
Masataka Ohta -
Nipper, Arnold -
Peter Galbavy -
Poul-Henning Kamp -
Stephane Bortzmeyer -
Stephen Burley -
Steven Bakker