<quote> Multihoming is popular because the cost of transmission circuits is plummeting, making it less expensive to buy Internet access services from two or more ISPs. At the same time, companies are more concerned about the reliability of their networks and less willing to trust one service provider. </quote> This gal only has it half right. It isn't the reduced cost of circuits, it's it's the uncertainty that that circuit's provider will still be in business next month, or that a change in that provider's business plans, or M&A activity, will make them abandon that circuit altogether. This coupled with 2+ month provisioning schedules. A dropped circuit will result in a 2+ month business outage. A 2 week business outage will put most companies out of business for good. How many, of Northpoint's 100K customers survived Northpoint's business failure? How many, of those that did, were multi-homed? How many of them are multi-homed now? <quote> "Half of the companies that are multihomed should have gotten better service from their providers," says Patrik Faltstrom, a Cisco engineer and co-chair of the IETF's Applications Area. "ISPs haven't done a good enough job explaining to their customers that they don't need to multihome." </quote> Is Patrik Faltstrom still an IETF co-chair? Is he still helping the [failing] credibility of the IETF? Maybe, that's why? How can any ISP, or anyone else, credibly guarantee that they'll still be in business next year? Or, that they wont sell out to the very rich bad guys? Or, that circuit provisioning will drop to under 5 calendar days? Because, that is the *only* way you will convince business customers that they don't need to multi-home. At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly cheap and getting cheaper), more RAM in the routers is a quick answer. Router clusters are another answer, and faster CPUs are yet another. All of the above, should get us by until we get a better router architecture. If the IETF is being at all effective, that should start now and finish sometime next year, so that we can start the 5-year technology roll-out cycle. The next time that PF goes out in public, he should either have his lips perma-bonded together, or have the lower part of his face covered in duct tape. Maybe then, he can resist the urge to chew on his feet. |> -----Original Message----- |> From: Irwin Lazar [mailto:ILazar@tbg.com] |> Sent: Thursday, August 23, 2001 2:35 PM |> To: 'nanog@merit.edu' |> Subject: multi-homing fixes |> |> |> |> A while back there was an article in Network World on |> problems due to the |> rise of multihoming: |> http://www.nwfusion.com/news/2001/0402routing.html which was |> discussed in |> great length in this forum. |> |> Has the IETF created a working group to deal with a |> long-term fix for this |> issue, and if so, is there a URL for its activities?
On Thu, Aug 23, 2001 at 03:23:24PM -0700, Roeland Meyer wrote:
At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly cheap and getting cheaper), more RAM in the routers is a quick answer. Router clusters
You almost make some good arguments. I pick up on this one for two reasons: 1) You clearly haven't priced Cisco RAM lately. :-) 2) You've missed the issue completely. You dance around ISP's providing more reliable service (eg, by adding RAM to their routers), and then dismiss that in the face of poor service and cheap prices people will buy multiple links. Much like your $99 RAM argument, customers today can get two or three T1's for the same price as one just a year ago. More bandwidth, more reliability, often less cost. Who would say no? Clearly ISP's should offer better service, but at the current bandwidth prices even with an ISP that took every precaution I, as a customer, would always buy from two people. The price really is that cheap. Even if ISP's (from a backbone perspective) delivered real 100% uptime, many people would buy two circuits (to different CO's) to avoid localized fiber / cable cuts. Multi-homing is here to stay, in a big way. It will only become more popular, no matter how good the ISP's become, for a number of reasons. Any future protocol or policy discussions should take this as a given. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Multi-homing is here to stay, in a big way. It will only become more popular, no matter how good the ISP's become, for a number of reasons. Any future protocol or policy discussions should take this as a given.
Please don't confuse "I need more than one pipe into the internet" with "my organization must place its prefixes into the default free zone". It is possible to effectively use multiple pipes into many ISPs without the cost to all of us that introducing your prefix into the DFZ has.
On Thu, 23 Aug 2001, Leo Bicknell wrote:
On Thu, Aug 23, 2001 at 03:23:24PM -0700, Roeland Meyer wrote:
At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly cheap and getting cheaper), more RAM in the routers is a quick answer. Router clusters
You almost make some good arguments. I pick up on this one for two reasons:
1) You clearly haven't priced Cisco RAM lately. :-)
Having the "Cisco" name on it and it working in Cisco equipment is a different story. Altough, we found out the hard way that RSP4 memory does NOT work in an RSP8. It'll boot on it but DON'T try to make it do anything after-the-fact. That said, you can get RAM for "cisco" products at many multiples less than Cisco wants to charge for it. --- John Fraizer EnterZone, Inc
Yes and this non cisco ram can make Cisco's tac have a cor or two.. Brian "Sonic" Whalen Success = Preparation + Opportunity On Thu, 23 Aug 2001, John Fraizer wrote:
On Thu, 23 Aug 2001, Leo Bicknell wrote:
On Thu, Aug 23, 2001 at 03:23:24PM -0700, Roeland Meyer wrote:
At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly cheap and getting cheaper), more RAM in the routers is a quick answer. Router clusters
You almost make some good arguments. I pick up on this one for two reasons:
1) You clearly haven't priced Cisco RAM lately. :-)
Having the "Cisco" name on it and it working in Cisco equipment is a different story. Altough, we found out the hard way that RSP4 memory does NOT work in an RSP8. It'll boot on it but DON'T try to make it do anything after-the-fact.
That said, you can get RAM for "cisco" products at many multiples less than Cisco wants to charge for it.
--- John Fraizer EnterZone, Inc
On Thu, Aug 23, 2001 at 09:31:29PM -0700, Brian Whalen wrote:
Yes and this non cisco ram can make Cisco's tac have a cor or two..
Cisco have certified a number of RAM vendors; you can happily buy RAM from them (at non-inflated prices) without voiding your warranty or causing an abnormal palpitations in the TAC. For example: http://www.kingston.com/memory/routerzone/default.asp Last time I priced RAM upgrades for RSP4s (which was a few years ago now) cisco list price was around five times greater than Kingston's price for cisco-approved SIMMs. Hooray, etc. Joe
Well I remember seeing a message on groupstudy where somone from the tac came on and made a statement along the lines that a substantial quantity of cases they get are a result of non Cisco memory. Brian "Sonic" Whalen Success = Preparation + Opportunity On Fri, 24 Aug 2001, Joe Abley wrote:
On Thu, Aug 23, 2001 at 09:31:29PM -0700, Brian Whalen wrote:
Yes and this non cisco ram can make Cisco's tac have a cor or two..
Cisco have certified a number of RAM vendors; you can happily buy RAM from them (at non-inflated prices) without voiding your warranty or causing an abnormal palpitations in the TAC.
For example:
http://www.kingston.com/memory/routerzone/default.asp
Last time I priced RAM upgrades for RSP4s (which was a few years ago now) cisco list price was around five times greater than Kingston's price for cisco-approved SIMMs. Hooray, etc.
Joe
Leo is exactly right. The real reasons that folks multihome are: 1) Backbone and/or routing instability striking one upstream provider 2) Local loop/fiber cuts That's pretty much it. Although there might be a small element of fear that a provider might go out of business, there is normally plenty of notice that a provider is going down, provided you are using a reputable business ISP and service, as opposed to DSL. I don't think multhoming needs to be limited, currently. The size of the routing table is increasing at a more or less linear rate, now. Even at a higher than linear rate, modern core routers used by most carriers (i.e. Juniper M-series and Cisco GSRs) can certainly handle a much large routing table, even in base configurations, with no memory upgrades. The number of routing updates is certainly not taxing router CPUs, either. We may run into scalability problems with the algorithm at some point, but it hasn't hit us yet. And, for now, CPU speed has been growing faster than the processing requirements of the table. The fact is, bandwidth is really cheap now. It is a "best practice" to have multiple providers of any resource that has a long lead-in time and that some or all of your business functions are dependant on. This article in NW is part of a distressing genre of similar skreeds, which have themes like "we are running out of IP address space, and must switch to IPv6, right now" or "the routing table is too big and the internet will melt down tomorrow". These articles appear in places like NW, Boardwatch, and Interactive Week. A greybeard from IETF is almost always trotted out as part of these tabloid-esqe little dramas. The uninformed and the semi-informed have a moment (or longer) of panic, then resume their lives, occasionally internalizing the misinformation. Multihoming is good for almost everyone who needs it, and NW writers need to do better research. - Daniel Golding -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Leo Bicknell Sent: Thursday, August 23, 2001 6:33 PM To: 'nanog@merit.edu' Subject: Re: multi-homing fixes On Thu, Aug 23, 2001 at 03:23:24PM -0700, Roeland Meyer wrote:
At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly cheap and getting cheaper), more RAM in the routers is a quick answer. Router clusters
You almost make some good arguments. I pick up on this one for two reasons: 1) You clearly haven't priced Cisco RAM lately. :-) 2) You've missed the issue completely. You dance around ISP's providing more reliable service (eg, by adding RAM to their routers), and then dismiss that in the face of poor service and cheap prices people will buy multiple links. Much like your $99 RAM argument, customers today can get two or three T1's for the same price as one just a year ago. More bandwidth, more reliability, often less cost. Who would say no? Clearly ISP's should offer better service, but at the current bandwidth prices even with an ISP that took every precaution I, as a customer, would always buy from two people. The price really is that cheap. Even if ISP's (from a backbone perspective) delivered real 100% uptime, many people would buy two circuits (to different CO's) to avoid localized fiber / cable cuts. Multi-homing is here to stay, in a big way. It will only become more popular, no matter how good the ISP's become, for a number of reasons. Any future protocol or policy discussions should take this as a given. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
I don't think multhoming needs to be limited, currently. The size of the routing table is increasing at a more or less linear rate, now.
please look at slides 11 and 15 of <http://psg.com/~randy/010809.ptomaine.pdf> the /24s of small multihomers is half the routing table (see geoff's data) and is growing radially (if you are silly enough not to filter that stuff). randy
On Fri, Aug 24, 2001 at 03:11:39PM -0700, Randy Bush wrote:
please look at slides 11 and 15 of
<http://psg.com/~randy/010809.ptomaine.pdf>
the /24s of small multihomers is half the routing table (see geoff's data) and is growing radially (if you are silly enough not to filter that stuff).
Does anyone have a graph of the number of allocated AS numbers? I ask because in a perfect world each AS would originate 1 prefix only, as they got enough address space in their first alloaction to service them forever. In that case growth of the AS table would be the growth of the routing table. The real world would never work like that of course, but it is an absolute lower bound on the table size, I think. I do believe we can get much closer to this world with address space sizes like those available in IPv6, however it's not clear to me that people are really trying to think that way. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
There are excellent graphs on http://www.arin.net/regserv/IPStats.html, now. Of course, this only shows the North American part of the picture. The brief summary is an extremely rapid growth in 1999 and 2000, with a much more modest growth this year. It would be an interesting "update" presentation at NANOG, if someone (maybe from ARIN), were to do a combined graphs of all RIR AS number and IP Address block growth, from ARIN, RIPE, and APNIC. This would also indicate the timeframe needed for deployment of software to support 4 byte AS numbers. FYI, recently issued AS numbers have been in the 22XXX area. - Daniel Golding -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Friday, August 24, 2001 6:18 PM To: Randy Bush Cc: Daniel Golding; Leo Bicknell; nanog@merit.edu Subject: Re: multi-homing fixes On Fri, Aug 24, 2001 at 03:11:39PM -0700, Randy Bush wrote:
please look at slides 11 and 15 of
<http://psg.com/~randy/010809.ptomaine.pdf>
the /24s of small multihomers is half the routing table (see geoff's data) and is growing radially (if you are silly enough not to filter that stuff).
Does anyone have a graph of the number of allocated AS numbers? I ask because in a perfect world each AS would originate 1 prefix only, as they got enough address space in their first alloaction to service them forever. In that case growth of the AS table would be the growth of the routing table. The real world would never work like that of course, but it is an absolute lower bound on the table size, I think. I do believe we can get much closer to this world with address space sizes like those available in IPv6, however it's not clear to me that people are really trying to think that way. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, Aug 24, 2001 at 09:52:31PM -0400, Daniel Golding wrote:
timeframe needed for deployment of software to support 4 byte AS numbers.
I have thought about a proposal, and I guess it's time to make it public. I know of several up-sides and down-sides to this already, but I won't list them for now to stimulate discussion. Rather than allocate AS numbers as we do today, why not make an AS simply be a globally unique 32 bit number, and establish a convention that AS numbers must come from a customer's netblock? That is, if I'm assigned 10.0.0.0/24, I could pick 10.0.0.1 as my "AS" number (or 10.0.0.37 for that matter) and I just start announcing it. The thought is many providers prefix filter routing announcements. The same filter could be applied to AS numbers. Networks would never have to 'allocate' ASN's (sorry arin, no $500 for you), and if they needed two they would just need 2 IP addresses. The global uniqueness is still guaranteed, and the owner can be tracked (via IP allocation, of course). Right now the up-sides and down-sides I know about cancel out in my view, so I can't put this forth as a proposal I support at the moment, but perhaps with some discussion I can be moved to the firmly a bad idea or firmly a good idea camp. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, Aug 24, 2001 at 09:52:31PM -0400, Daniel Golding wrote:
timeframe needed for deployment of software to support 4 byte AS numbers.
I have thought about a proposal, and I guess it's time to make it public. I know of several up-sides and down-sides to this already, but I won't list them for now to stimulate discussion.
There is at least a Internet Draft on the subject now. One could lean on vendor of choice today and ask for them.
Rather than allocate AS numbers as we do today, why not make an AS simply be a globally unique 32 bit number, and establish a convention that AS numbers must come from a customer's netblock? That is, if I'm assigned 10.0.0.0/24, I could pick 10.0.0.1 as my "AS" number (or 10.0.0.37 for that matter) and I just start announcing it.
See early IPv6, ISIS, etc for more on this tactic.
Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
IIRC, the IPv6 address string includes a field for your AS number. I don't recall the bit length of that field, though. (in addition to a field designating what PLANET you're on...) -Chris
Rather than allocate AS numbers as we do today, why not make an AS simply be a globally unique 32 bit number, and establish a convention that AS numbers must come from a customer's netblock? That is, if I'm assigned 10.0.0.0/24, I could pick 10.0.0.1 as my "AS" number (or 10.0.0.37 for that matter) and I just start announcing it.
The thought is many providers prefix filter routing announcements. The same filter could be applied to AS numbers. Networks would never have to 'allocate' ASN's (sorry arin, no $500 for you), and if they needed two they would just need 2 IP addresses. The global uniqueness is still guaranteed, and the owner can be tracked (via IP allocation, of course).
Right now the up-sides and down-sides I know about cancel out in my view, so I can't put this forth as a proposal I support at the moment, but perhaps with some discussion I can be moved to the firmly a bad idea or firmly a good idea camp.
-- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
This would also indicate the timeframe needed for deployment of software to support 4 byte AS numbers. FYI, recently issued AS numbers have been in the 22XXX area.
Much of this thread appears to be operating under the flawed assumption that the only ways to multihome[1] involve inserting prefixes of some size (under dispute) into the global[2] routing table. Sure, at the moment, that is predominantly the way things work. But beyond bitching at eachother about filtering policies (which has a long record of productive results... mmm...), consider technologies that can change this. Well, let's assume the routing table remains static across a failure (and hence we don't have to introduce prefixes). We need some technology which acts as an indirection mechanism in the case of a failure. One such technology possibly ripe for perversion is DNS. Another is mobile IP. Sure, these may not be great for the application right now, but they both share a key advantage, which is that the deployer pays (not the rest of the internet). Assuming the a fixed % of users multihome (and it's likely to increase), and assuming a fixed cost per prefix supported (OK, so that's likely to decrease), the costs are O(n) rather than O(n^2). And some of these technologies have other advantages. BGP traffic engineering is difficult (tm), in that it is is almost impossible to present a list of 2-tuples (correspondant, pipe), and get BGP to work that way in anything other than the outbound direction, and dynamic traffic management (responding to congestion) is hard. Indirected technologies (DNS being an obvious one as it exists, though it's less than ideal), don't have to suffer the same limitations. [1] = let's define that, for convenience, as to connect to n>1 different providers of IP connectivity, possibly utilizing redundant tail circuits, in a manner where if one or more, but not all providers fail, service is degraded as little as possible. [2] = less than global, if it becomes balkanized filtering in response to uncontrolled proliferation of long prefix routes -- Alex Bligh Personal Capacity
This would also indicate the timeframe needed for deployment of software to support 4 byte AS numbers. FYI, recently issued AS numbers have been in the 22XXX area.
Much of this thread appears to be operating under the flawed assumption that the only ways to multihome[1] involve inserting prefixes of some size (under dispute) into the global[2] routing table.
Alex, Total agreement, and that's why I have written a user requirements draft and posted a suggestion of a focal point for information yesterday. If the only tool you have is a BGP hammer, everything looks like a nail. There are lots of other tools, but no one has ever, it seemed, cataloged the toolbox, and written down a beginner's guide to their applications.
[1] = let's define that, for convenience, as to connect to n>1 different providers of IP connectivity, possibly utilizing redundant tail circuits, in a manner where if one or more, but not all providers fail, service is degraded as little as possible.
[2] = less than global, if it becomes balkanized filtering in response to uncontrolled proliferation of long prefix routes
-- Alex Bligh Personal Capacity
On Sat, 25 Aug 2001 14:55:51 BST, Alex Bligh said:
One such technology possibly ripe for perversion is DNS. Another is mobile IP. Sure, these may not be great for the application right now, but they both share a key advantage, which is that the deployer pays (not the rest of the internet). Assuming the a fixed % of users multihome (and it's likely to increase), and assuming a fixed cost per prefix supported (OK, so that's likely to decrease), the costs are O(n) rather than O(n^2).
Do you *really* want your DNS TTL set down in the same range as the time for a BGP route fall-over? We usually run with hign TTLs, and drop them down before impending changes. Unfortunately, there's no easy way to do that 24 hours before the backhoe gets there... Also, if you run BigSite.com and drop your DNS TTL, I *do* pay, because now my DNS server has to hit the network for a look-up for your site - you just added several packets to the transaction. Given that we have an on-site Akamai node, for some sites, the DNS lookup could be 10% of the total traffic on our outbound pipe for each page hit....
On Sat, Aug 25, 2001 at 12:19:42PM -0400, Valdis.Kletnieks@vt.edu wrote:
One such technology possibly ripe for perversion is DNS. Another is mobile IP. Sure, these may not be great for the application right now, but they both share a key advantage, which is that the deployer pays (not the rest of the internet). Assuming the a fixed % of users multihome (and it's likely to increase), and assuming a fixed cost per prefix supported (OK, so that's likely to decrease), the costs are O(n) rather than O(n^2).
Do you *really* want your DNS TTL set down in the same range as the time for a BGP route fall-over?
Ever read RFC1123? It states: 2.3 Applications on Multihomed hosts When the remote host is multihomed, the name-to-address translation will return a list of alternative IP addresses. As specified in Section 6.1.3.4, this list should be in order of decreasing preference. Application protocol implementations SHOULD be prepared to try multiple addresses from the list until success is obtained. More specific requirements for SMTP are given in Section 5.3.4. When the local host is multihomed, a UDP-based request/response application SHOULD send the response with an IP source address that is the same as the specific destination address of the UDP request datagram. The "specific destination address" is defined in the "IP Addressing" section of the companion RFC [INTRO:1]. Similarly, a server application that opens multiple TCP connections to the same client SHOULD use the same local IP address for all. Unfortunately, many programs have chosen not to do this. -- Med venlig hilsen / Sincerely Andreas Plesner Jacobsen (Network Engineer) / Tiscali A/S (World Online) Peter Bangs Vej 26, DK-2000 Frederiksberg - http://www.tiscali.dk Tlf. +45 3814 7000 - Fax +45 3814 7007
Do you *really* want your DNS TTL set down in the same range as the time for a BGP route fall-over?
Q: what is the route convergence time of 'the internet', for any given route? It is certainly larger than BGP route fall-over time. DNS may well not be an ideal protocol for doing this [1]. However, as Howard eloquently posted earlier, I was rather evidencing that BGP isn't the only tool available, and is certainly not the only tool possible. Heh, may be we'll have to go do some work on a new one, or enhance a current one. [1] = you may well find that client stacks are a larger problem.
We usually run with hign TTLs, and drop them down before impending changes. Unfortunately, there's no easy way to do that 24 hours before the backhoe gets there...
So you /could/ always run it low. Look at technologies like ultradns / nominum, to see how this can actually work well. And feed that database (far easier distribution problem) from your reachability information.
Also, if you run BigSite.com and drop your DNS TTL, I *do* pay, because now my DNS server has to hit the network for a look-up for your site - you just added several packets to the transaction.
Ummm, so if X is accessing Y's site, Y pays for some of the network costs, and X pays for some of the network costs. However, at least in this proposal Z (unconnected 3rd party) doesn't suffer - he does suffer from routing table bloat. The suggestion that the users (both source and destination) should pay for performance, rather than the rest of the internet in general, is, of course, shocking to some :-) Alex
On Fri, 24 Aug 2001, Randy Bush wrote:
I don't think multhoming needs to be limited, currently. The size of the routing table is increasing at a more or less linear rate, now.
please look at slides 11 and 15 of
<http://psg.com/~randy/010809.ptomaine.pdf>
the /24s of small multihomers is half the routing table (see geoff's data) and is growing radially (if you are silly enough not to filter that stuff).
You mean there are more smaller guys than larger ones? Bogggle.
On Fri, Aug 24, 2001 at 03:19:51PM -0700, Patrick Greenwell wrote:
the /24s of small multihomers is half the routing table (see geoff's data) and is growing radially (if you are silly enough not to filter that stuff).
You mean there are more smaller guys than larger ones?
And what's small? CNN with a /24? eBay with a /24? Traffic wise they are certainly not small, visability wise they are certainly not small, and I'm pretty sure no one here will claim that. Yet both annouce /24's out of the Classful C space and get listened to (atleast by Verio who is a known filterer). -- ------------------------------------------------------------------------------- : Steven Noble / Network Janitor / Be free my soul and leave this world alone : : My views = My views != The views of any of my past or present employers : -------------------------------------------------------------------------------
On Fri, Aug 24, 2001 at 04:26:52PM -0700, Steve Noble wrote:
And what's small? CNN with a /24? eBay with a /24? Traffic wise they are certainly not small, visability wise they are certainly not small, and I'm pretty sure no one here will claim that. Yet both annouce /24's out of the Classful C space and get listened to (atleast by Verio who is a known filterer).
And don't forget, if they had asked for address space back in 1988-1990 they would be announcing a /16, and using a /24 of it. The average routing announcement has gotten smaller as a result of tighter allocation policies. The use 80% rule and all that. Of course all the growth is in small prefixes. You can't get a large prefix these days, and if you get a smaller one that should be aggregatable to a larger prefix next time you ask the likelyhood it will still be there when you ask for it is low. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, Aug 24, 2001 at 07:33:50PM -0400, Leo Bicknell wrote:
And don't forget, if they had asked for address space back in 1988-1990 they would be announcing a /16, and using a /24 of it.
I had a much bigger email I postponed to see what happened in this thread, that was part of it. It also included IANA's allocation to themselves in the 192.0/16 (RESERVED) space.. It would be interesting to see what would have happened if they had allocated and annouced a /24 from the 64/8 space. Would Verio be unable to reach them? (You can substitute Verio for any other heavily filtering provider) What makes joe blow with his ancient /16 that he's using 7 hosts on better then a site that wants to NOT waste space annoucing a /24 that is invisible to part of the Internet due to filters.
The average routing announcement has gotten smaller as a result of tighter allocation policies. The use 80% rule and all that.
Which is valid.. Now on the other hand by saying "and if it's smaller then a /20 you will be filtered" you cause undue pressure on people to "spin" their designs in ways to show that they can use a /20 and get the allocation from ARIN directly. These two arguments cause some issues with eachother.
Of course all the growth is in small prefixes. You can't get a large prefix these days, and if you get a smaller one that should be aggregatable to a larger prefix next time you ask the likelyhood it will still be there when you ask for it is low.
The whole problem seems to me to be a lack of a micro-allocation policy, and an agreement from providers that they will not filter that space. -- ------------------------------------------------------------------------------- : Steven Noble / Network Janitor / Be free my soul and leave this world alone : : My views = My views != The views of any of my past or present employers : -------------------------------------------------------------------------------
Now on the other hand by saying "and if it's smaller then a /20 you will be filtered" you cause undue pressure on people to "spin" their designs in ways to show that they can use a /20 and get the allocation from ARIN directly.
you mean not use nat? should i be broken-hearted?
The whole problem seems to me to be a lack of a micro-allocation policy, and an agreement from providers that they will not filter that space.
judicious use of this might be helpful. the problem is the 'judge' in judicious. randy
On Fri, Aug 24, 2001 at 04:51:15PM -0700, Randy Bush wrote:
Now on the other hand by saying "and if it's smaller then a /20 you will be filtered" you cause undue pressure on people to "spin" their designs in ways to show that they can use a /20 and get the allocation from ARIN directly.
you mean not use nat? should i be broken-hearted?
Great. I use NAT. I have a single IP address, can't get much better than that. How do I multihome with my /32? This is a serious question, several large web sites are a single IP that is translated by "nat"; load balancers actually. If you want to argue everyone should use NAT, you need to do that hand in hand with a method for making smaller allocations multi-home capable, or you've only solved half the problem, and thus have a useless solution. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, Aug 24, 2001 at 04:51:15PM -0700, Randy Bush wrote:
Now on the other hand by saying "and if it's smaller then a /20 you will be filtered" you cause undue pressure on people to "spin" their designs in ways to show that they can use a /20 and get the allocation from ARIN directly.
you mean not use nat? should i be broken-hearted?
NAT?!? You are obviously not understanding the point I was attempting to make. The point was that companies may not need more then a /24 to put their entire site on, yet may be pushed to say they have more in order to acquire a /20 from ARIN, just to be globally visable. If you were in a position where you did NOT have your own previously allocated swamp/b/a space, you wanted to multihome to a few different providers in such a way that you were globally reachable no matter who went offline and you only needed a /24 or less, what would you do? -- ------------------------------------------------------------------------------- : Steven Noble / Network Janitor / Be free my soul and leave this world alone : : My views = My views != The views of any of my past or present employers : -------------------------------------------------------------------------------
The global visibility point you address isn't that hard to solve. Most service providers you buy service from, if you tell em you're going to multihome to multiple providers, well they all know that a mask longer than /24 id to be filtered for sure and will allocate a /24 just based on multihoming, even if a smaller portion of the ips is all that is needed. Problems occur when you try to announce the /24 out of classful A or B space. Brian "Sonic" Whalen Success = Preparation + Opportunity On Fri, 24 Aug 2001, Steve Noble wrote:
On Fri, Aug 24, 2001 at 04:51:15PM -0700, Randy Bush wrote:
Now on the other hand by saying "and if it's smaller then a /20 you will be filtered" you cause undue pressure on people to "spin" their designs in ways to show that they can use a /20 and get the allocation from ARIN directly.
you mean not use nat? should i be broken-hearted?
NAT?!? You are obviously not understanding the point I was attempting to make.
The point was that companies may not need more then a /24 to put their entire site on, yet may be pushed to say they have more in order to acquire a /20 from ARIN, just to be globally visable.
If you were in a position where you did NOT have your own previously allocated swamp/b/a space, you wanted to multihome to a few different providers in such a way that you were globally reachable no matter who went offline and you only needed a /24 or less, what would you do?
-- ------------------------------------------------------------------------------- : Steven Noble / Network Janitor / Be free my soul and leave this world alone : : My views = My views != The views of any of my past or present employers : -------------------------------------------------------------------------------
On Fri, Aug 24, 2001 at 05:20:17PM -0700, Brian Whalen wrote:
The global visibility point you address isn't that hard to solve. Most service providers you buy service from, if you tell em you're going to multihome to multiple providers, well they all know that a mask longer than /24 id to be filtered for sure and will allocate a /24 just based on multihoming, even if a smaller portion of the ips is all that is needed. Problems occur when you try to announce the /24 out of classful A or B space.
Now that's confusing.. doesn't CIDR supposedly make it so that one IP is no better or worse then another? Why do people base their filtering policies on where things are in the "Classful" space? How is 64/8 any different then 216/8.. they allocate out of both of them, it's a crapshoot what you get since ARIN denys responsibility to provide routable IP space, yet there is space that is "more" routable than other space. -- ------------------------------------------------------------------------------- : Steven Noble / Network Janitor / Be free my soul and leave this world alone : : My views = My views != The views of any of my past or present employers : -------------------------------------------------------------------------------
Now that's confusing.. doesn't CIDR supposedly make it so that one IP is no better or worse then another? Why do people base their filtering policies on where things are in the "Classful" space? How is 64/8 any different then 216/8.. they allocate out of both of them, it's a crapshoot what you get since ARIN denys responsibility to provide routable IP space, yet there is space that is "more" routable than other space.
you may want to look at the rirs' web pages where they report what prefix sizes have been allocated out of which /8s. that is what some folk use for prefix filtering policies. randy
On Fri, 24 Aug 2001, Steve Noble wrote:
Now that's confusing.. doesn't CIDR supposedly make it so that one IP is no better or worse then another? Why do people base their filtering policies on where things are in the "Classful" space? How is 64/8 any different then 216/8.. they allocate out of both of them, it's a crapshoot what you get since ARIN denys responsibility to provide routable IP space, yet there is space that is "more" routable than other space.
If we must filter based on minimum allocation boundaries, a new "classful" definition of networks is exactly what we need. Many carriers that have /16's or bigger out of 6x/8 slice and dice it up into multiple /19's and /20's. How is this different from me slicing a /20 up into 16 individual /24's? It's still someone advertising 16 prefixes instead of one, and it causes just as much bloat. but since the prefix lengths are "small enough" to pass through the aggregation police it's for some reason or another considered ok. Unless the RIR's put something out along the lines of: /16's and greater will be allocated out of x/8 /17's will be allocated out of x/8 /18's will be allocated out of x/9 /19's will be assigned out of x/10 /20's will be assigned out of x/10 the filtering methods talked about here will only be half as effective as they should, and some of the worst offenders still get to bloat the tables as much as always. Sure it makes filtering more difficult, but hey if you want to do it, do it right. I know that many questions come up like "what if i get a /20, then another contiguous /20 that can be summarized as a /19" .. that just brings up more questions on how to address the current problems of handing out address space. Paul
If you were in a position where you did NOT have your own previously allocated swamp/b/a space, you wanted to multihome to a few different providers in such a way that you were globally reachable no matter who went offline and you only needed a /24 or less, what would you do?
haven't thought about it for a while, but ... probably rethink my requirements a bit. my small experiences running a site or two lead me to think physical diversity in the local loop is by far my biggest concern, like ten to one or worse over a provider problem. and then, almost all the provider problems i can remember my site having were a router needing geritol or, quite rarely, a pop going bad. i have not had a whole isp go out from under me since the bad old days. but i have tried to stay with reliable providers. so i might seriously consider dual homing to separate pops of a single very reliable isp, and concentrating my energy on physical diversity of the local loop. if i really felt the need for multiple providers, i might do a double nat, but with full 1:1 mapping, i.e. pure address aliasing, not space compression. of course, some persistent connections would be lost in the case of a link failure. but insurance against very rare cases is ok if the expense is incurred on the rare case. randy
On Fri, Aug 24, 2001 at 05:22:03PM -0700, Randy Bush wrote:
haven't thought about it for a while, but ... probably rethink my requirements a bit.
Let me give you the first two requirements: 1) Your investors won't give you money unless you have 'redundant' connectivity for your e-whatever. 2) Your insurance auditors won't give you insurance for your e-whatever unless you have 'redundant' connectivity.
so i might seriously consider dual homing to separate pops of a single very reliable isp, and concentrating my energy on physical diversity of the local loop.
I believe you just limited yourself to an amazingly small number of providers, if any at all. Even in the large metro areas where providers _might_ have two POPs, they are often fairly dependant on a third location (ie 60 Hudson, 1 Wilshire) which in many cases could just be an aggregation POP for that provider in the region. How many cities does Verio have two POP's in set up in such a way that the loss of all or part of one POP would result in almost no effect on the other POP?
if i really felt the need for multiple providers, i might do a double nat, but with full 1:1 mapping, i.e. pure address aliasing, not space compression. of course, some persistent connections would be lost in the case of a link failure. but insurance against very rare cases is ok if the expense is incurred on the rare case.
You want to explain that in a bit more detail. Start with 'client looks up www.example.com' and go to 'client establishes tcp connection with the web server that services the content'. Having DNS point at 2 IP's and having one "not be there" is not a valid answer, it doesn't work in the real world. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Steve Noble <snoble@sonn.com> writes:
The point was that companies may not need more then a /24 to put their entire site on, yet may be pushed to say they have more in order to acquire a /20 from ARIN, just to be globally visable.
Right, just as they are already pushed to get /24 blocks without really needing them.
If you were in a position where you did NOT have your own previously allocated swamp/b/a space, you wanted to multihome to a few different providers in such a way that you were globally reachable no matter who went offline and you only needed a /24 or less, what would you do?
A couple more comments. 1. Customers requesting address blocks today - possibly due to a simple change of ISP - may get new /24 allocations from 63/8 and similar lowly turf because that is what is available. Verio (are there others?) filters prefixes from these players on the basis of first octet. Not sure why somebody is more of a threat to the net from 63/8 than from 207/8. 2. Raising the bar on filtering to block /24 would penalize customers who want to be good netizens by doing rfc2260-ish multihoming, where long prefixes are advertised only in failure mode.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Randy Bush Sent: Friday, August 24, 2001 7:51 PM To: Steve Noble Cc: nanog@merit.edu Subject: Re: multi-homing fixes
The whole problem seems to me to be a lack of a micro-allocation policy, and an agreement from providers that they will not filter that space.
judicious use of this might be helpful. the problem is the 'judge' in judicious.
indeed. but it would still disassociate the space conservation and table growth problems to some extent; the "judge" being the same as today.
randy -- dima.
The whole problem seems to me to be a lack of a micro-allocation policy, and an agreement from providers that they will not filter that space. judicious use of this might be helpful. the problem is the 'judge' in judicious. indeed. but it would still disassociate the space conservation and table growth problems to some extent; the "judge" being the same as today.
ahhh, somebody understood the comment. the problem is that there is no obvious detent on the knob. to start the usual posturing and flamage, i propose min 2xDS3 multihomed. randy
ahhh, somebody understood the comment.
the problem is that there is no obvious detent on the knob. to start the usual posturing and flamage, i propose min 2xDS3 multihomed.
randy
The only reason we multihomed to 2xT1 rather than adding additional capacity with our first provider lack of clue. Minimum downtime for ANY incident was 30 minutes waiting for a level one (L1) tech to enter basic information. After working hours you could argue for 30 minutes with a L2 about getting a page to a L3 who could actually make a change to the routers. Efficient process, eh? It would have been completely unconscionable to our dedicated customers to continue with a single provider. How do you propose that a small ISP grow large enough to afford a 2xDS3 connection when even a minor fubar at the (single) upstream will cause outages for ALL of the ISP's customers? If we are taking votes mine would be having an AS number. Mark Radabaugh Amplex (419) 833-3635
The only reason we multihomed to 2xT1 rather than adding additional capacity with our first provider lack of clue.
so the world should pay because you won't choose a reliable/reasonable provider?
How do you propose that a small ISP grow large enough to afford a 2xDS3
an isp usually has a /20-/21, yes? we're talking about MICRO allocations. randy
On Tue, 28 Aug 2001, Randy Bush wrote:
The only reason we multihomed to 2xT1 rather than adding additional capacity with our first provider lack of clue.
so the world should pay because you won't choose a reliable/reasonable provider?
Please provide a definitive list of such providers.
On Mon, 27 Aug 2001 21:59:51 PDT, Patrick Greenwell said:
so the world should pay because you won't choose a reliable/reasonable provider?
Please provide a definitive list of such providers.
Sturgeon's Law applies here too. /Valdis (who spent part of last night being amazed at an OC-3 that was showing 15000ms packet delays. On a terrestrial link. From a big-name provider. Yes, there's 3 zeros in that. No, the router on our end of the OC-3 doesn't have THAT much buffer space - that's why I was amazed)
On Tue, 28 Aug 2001, Randy Bush wrote:
an isp usually has a /20-/21, yes?
we're talking about MICRO allocations.
How micro is MICRO? /30? /28? /23? Define that, and you may stop a flamefest before it turns into a weeklong procmail adventure. C
randy
an isp usually has a /20-/21, yes? we're talking about MICRO allocations. How micro is MICRO? /30? /28? /23?
probably 24 and longer. a big web site, not an isp.
Define that, and you may stop a flamefest before it turns into a weeklong procmail adventure.
my mail system has kill-subject and i have the worst non-contributors procmailed. protect your own network. :-) randy
On Mon, Aug 27, 2001 at 10:56:51PM -0400, Mark Radabaugh - Amplex wrote:
The only reason we multihomed to 2xT1 rather than adding additional capacity with our first provider lack of clue. Minimum downtime for ANY
While there is a great lack of clue in many locations, don't forget the bean counters/marketing/sales. In an outage, virtually all ISP's prioritize customer restoriation, and sometimes the quality of the engineer working the incident by the size of the circuit (which presumably translates into $$$'s, but that's a whole different tarball). Thus, one could conclude that the lowest speed circuits get the "worst" service, and thus those with the smallest bandwidth needs have the largest need to multihome. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Tue, 28 Aug 2001, Leo Bicknell wrote:
While there is a great lack of clue in many locations, don't forget the bean counters/marketing/sales.
In an outage, virtually all ISP's prioritize customer restoriation, and sometimes the quality of the engineer working the incident by the size of the circuit (which presumably translates into $$$'s, but that's a whole different tarball). Thus, one could conclude that the lowest speed circuits get the "worst" service, and thus those with the smallest bandwidth needs have the largest need to multihome.
The interesting part is that when we were single homed a upstream outage was a HUGE deal and generated very demanding calls to the upstreams support staff. Now when we loose an upstream it generates a shrug and a phone call - so... Multihomed customers generate LESS technical support rather than more? Maybe we should urge more people to multihome... Mark
On Tue, 28 Aug 2001, Mark Radabaugh wrote:
On Tue, 28 Aug 2001, Leo Bicknell wrote:
While there is a great lack of clue in many locations, don't forget the bean counters/marketing/sales.
In an outage, virtually all ISP's prioritize customer restoriation, and sometimes the quality of the engineer working the incident by the size of the circuit (which presumably translates into $$$'s, but that's a whole different tarball). Thus, one could conclude that the lowest speed circuits get the "worst" service, and thus those with the smallest bandwidth needs have the largest need to multihome.
The interesting part is that when we were single homed a upstream outage was a HUGE deal and generated very demanding calls to the upstreams support staff. Now when we loose an upstream it generates a shrug and a phone call - so...
Multihomed customers generate LESS technical support rather than more? Maybe we should urge more people to multihome...
Mark
"Multihomed customers generate LESS technical support rather than more?" Perhaps in an outage instance they do. When they have a routing issue, it can become a finger-pointing match between their upstreams and thus, it generates 100% more technical support for the upstream who doesn't have the problem. --- John Fraizer EnterZone, Inc
"Multihomed customers generate LESS technical support rather than more?" Perhaps in an outage instance they do. When they have a routing issue, it can become a finger-pointing match between their upstreams and thus, it generates 100% more technical support for the upstream who doesn't have the problem.
--- John Fraizer EnterZone, Inc
There was a question mark after that statement :-) So far FUBARS by provider A have not generated any extra technical support for provider B. At least in a simple multihome situation it isn't too hard to tell who is hosing things using online routing tools. It may generate more traffic to B but I don't see it causing a support issue. Mark
On Fri, 24 Aug 2001 16:26:52 PDT, Steve Noble said:
And what's small? CNN with a /24? eBay with a /24? Traffic wise they are certainly not small, visability wise they are certainly not small, and I'm pretty sure no one here will claim that. Yet both annouce /24's out of the Classful C space and get listened to (atleast by Verio who is a known filterer).
The Fourth Law of real-world routing table management: No matter how pure of heart, noble of spirit, and determined to filter at /19, You *will* end up punching out holes for things like a CNN /24 or an eBay /24 just to make the phone stop ringing.... ;)
Been following this discussion closely, as multihoming has always been an interest of mine, going back to my first NANOG presentation in San Francisco. I am working on a couple of things in this area, which were presented at the last IETF: http://www.ietf.org/internet-drafts/draft-berkowitz-multireq-02.txt and http://www.ietf.org/internet-drafts/draft-berkowitz-tblgrow-00.txt The first deals with a broad framework for multihoming and related topics, but from the user requirements standpoint. The second proposes heuristics for trying to get a better understanding why the table is growing -- multihoming, lack of clue, traffic engineering, etc. Part of the problem is that user perceptions and desires may or may not result in picking the right tool to get what they really want, which typically is high availability and load distribution. Honest, I had a customer that insisted their Internet connection never go down. I arranged BGP multihoming to two ISPs, and had one of the connections engineered so that it came directly off a major provider's dual SONET that entered their office park. Some time later, I was in their computer room, and found -- count 'em -- ONE application server. I inquired what they planned to do if it went down, and they assured me that they were OK because they backed up on tape. Horrible shocked expressions when I inquired to what they expected to restore the tape. I started the multihoming framework paper when I was consulting on pre-sales design to a major carrier, that would get weird customer perceptions but have no independent references to educate them. I've also written books in this area -- not intended as a plug, but another resource. What I sense that we, as operators, vendors to operators, etc., need is some common vocabulary and methodology to understand what the customer is trying to do, and help them see the correct picture and the correct tools. The tools might be server clustering, redundant and diverse local loops to the same provider, contractual requirements for upstream route diversity, DNS redirection, etc. My increasing feeling is that we lack a focal point for such information. I've variously presented drafts to IDR, MULTI6, and PTOMAINE, but the fit is never quite right. My inclination is to suggest BOF-level activities both at the operational forums and IETF, and try to replicate some of what we did in the PIER working group on renumbering -- not invent tools, but provide operational guidance. I'm thinking of requesting a BOF on this both at NANOG in Oakland, and then the IETF in Salt Lake City. Tentative name: "Multihoming User Requirements at All Layers (MURAL)". Might this help the situation? Howard Berkowitz Nortel Networks
Sorry for the late reply. On Fri, 24 Aug 2001, Randy Bush wrote:
the /24s of small multihomers is half the routing table (see geoff's data)
This can't possibly be correct. The last figure I read was that there are about 70k /24s. There are about 21k AS numbers out there. This means that by far most of the announcements, including /24s, are the result of lack of CIDR. Either because ISPs have a relatively large number of PA blocks (address conservation) or because of lack of aggregation.
On Wed, Aug 29, 2001 at 07:12:19PM +0200, Iljitsch van Beijnum wrote:
Sorry for the late reply.
On Fri, 24 Aug 2001, Randy Bush wrote:
the /24s of small multihomers is half the routing table (see geoff's data)
This can't possibly be correct. The last figure I read was that there are about 70k /24s. There are about 21k AS numbers out there. This means that by far most of the announcements, including /24s, are the result of lack of CIDR. Either because ISPs have a relatively large number of PA blocks (address conservation) or because of lack of aggregation.
Small multihomer /24s aren't necessarily their own. I've dealt with plenty of customers multihoming with a /24 from their other provider without running BGP. No extra AS number, but the /24 still shows up in the global table. Also seen customers with their own /24, but having us originate it rather than doing BGP with them. -c
On Wed, 29 Aug 2001, Clayton Fiske wrote:
the /24s of small multihomers is half the routing table (see geoff's data)
This can't possibly be correct. The last figure I read was that there are about 70k /24s. There are about 21k AS numbers out there. This means that by far most of the announcements, including /24s, are the result of lack of CIDR. Either because ISPs have a relatively large number of PA blocks (address conservation) or because of lack of aggregation.
Small multihomer /24s aren't necessarily their own. I've dealt with plenty of customers multihoming with a /24 from their other provider without running BGP. No extra AS number, but the /24 still shows up in the global table. Also seen customers with their own /24, but having us originate it rather than doing BGP with them.
I've never dealt with a customer with such a setup, but with at least a dozen BGP multihomers. I'm sure that people are multihoming this way, but I'm not so sure these BGP-less multihomers make up half the routing table. I've tried to gather some statistics. They aren't very good, but what I got was 1209 "inconsitent paths" below 212.x.x.x. Apart from the people who don't aggregate the high number or /24s in the global routing table is probably also to a large extent due to people not wanting to renumber and taking addresses with them to another ISP.
On Fri, Aug 24, 2001 at 06:04:19AM -0400, Daniel Golding wrote:
Leo is exactly right. The real reasons that folks multihome are:
1) Backbone and/or routing instability striking one upstream provider 2) Local loop/fiber cuts
That's pretty much it.
how about, 3) The desire to have the customers of backbone providers with rather different customer bases be able to efficiently reach a target site? (example: a US provider with lots of business customers, a dial-up/DSL concentrator, and a European provider with lots os EU customers; you might choose to buy transit from all three) -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
On Fri, Aug 24, 2001 at 06:04:19AM -0400, Daniel Golding wrote:
Leo is exactly right. The real reasons that folks multihome are:
1) Backbone and/or routing instability striking one upstream provider 2) Local loop/fiber cuts
That's pretty much it.
how about, 3) The desire to have the customers of backbone providers with rather different customer bases be able to efficiently reach a target site? (example: a US provider with lots of business customers, a dial-up/DSL concentrator, and a European provider with lots os EU customers; you might choose to buy transit from all three)
There are many, many more reasons. To begin with: 4) Desire not to be held hostage by your ISP when billing disputes or other problems occur. 5) Desire for additional leverage when negotiating with your ISP, "I can pull my circuit to you right now and my network will not be affected. If you can't match my latest offer from XYZ Corp, I'll just flip the switch." 6) Ability to reduce the average number of hops between your networks and various important other sites. Ability to reduce the points at which outages or packet loss can occur. 7) The comfort of knowing you won't have to worry about the latest crazy idea your ISP dreams up. For example, "Starting thursday, we require all IPs to have valid, matching forward and reverse DNS or we won't route to them". I'm sure people have other examples of similar insanities. 8) No need to worry about what happens if your ISP gets slow or overcommitted. You just shut them off while you find another ISP to replace them. There are more reasons. These are just a small number of them. DS
By the way, my favorite provider insanity (circa 1998) went like this: Provider: We need 80% of your IPs to be pingable by next week or we're going to have to take some of your IPs away. Customer: This is coming out of nowhere. That requirement isn't in our contract. P: Your contract says that you have to follow our IP allocation policies and if you don't we can take them back. So, our new policy is that 80% of your IPs have to be pingable. C: Well that's a problem because about 40% of my IPs have been allocated to customers who have asked me to block incoming pings, which I do. P: Well, I'm sorry, that's just the way it is. We need the IPs badly and ARIN won't allocate us any more right now. So we need you to prove usage or we'll take them back. C: I have an idea. If you can tell me what IP or small block of IPs you'll be pinging from, I'll talk to the affected customers about making an exception for your ping boxes. P: I'm sorry, I can't tell you that information. C: Why not? P: If you knew where we'd be pinging from, you could block our pinger. Then we'd have no idea what IPs you were using. Most likely, this particular provider had done something majorly wrong for their allocations to be refused. But it's their customers that suffer. This alone is sufficient reason to multihome. It lets you keep your hair. DS
At 18:23 23/08/01, Roeland Meyer wrote:
<quote> "Half of the companies that are multihomed should have gotten better service from their providers," says Patrik Faltstrom, a Cisco engineer and co-chair of the IETF's Applications Area. "ISPs haven't done a good enough job explaining to their customers that they don't need to multihome." </quote>
Is Patrik Faltstrom still an IETF co-chair? Is he still helping the [failing] credibility of the IETF? Maybe, that's why? How can any ISP, or anyone else, credibly guarantee that they'll still be in business next year? Or, that they wont sell out to the very rich bad guys? Or, that circuit provisioning will drop to under 5 calendar days? Because, that is the *only* way you will convince business customers that they don't need to multi-home.
Rather than just bash the IETF (which is easy), it might be just slightly more productive to wander over, subscribe to the relevant list(s), and inject some operational perspective and/or clue. Browsing http://www.ietf.org will yield information on current draft, WG charters, and how to join any lists of interest.
At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly cheap and getting cheaper), more RAM in the routers is a quick answer. Router clusters are another answer, and faster CPUs are yet another. All of the above, should get us by until we get a better router architecture. If the IETF is being at all effective, that should start now and finish sometime next year, so that we can start the 5-year technology roll-out cycle.
One belief (right or wrong) is the end-to-end path convergence algorithm in BGP is close to hitting its scaling limits. That's a problem that infinite RAM could not solve. A proof that the algorithm is not a danger here would be most welcome in many circles. If you've got such a proof, please do share. Ran rja@inet.org
On Thu, Aug 23, 2001 at 03:23:24PM -0700, Roeland Meyer wrote:
This gal only has it half right. It isn't the reduced cost of circuits, it's it's the uncertainty that that circuit's provider will still be in business next month, or that a change in that provider's business plans, or M&A activity, will make them abandon that circuit altogether [...]
I don't think anyone here is concerned that vZn, SBC, WCOM, Q, etc will go out of business, or undergo drastic business changes prohibiting them from continuing to provide us with the TDM, xWDM, dark fibre, etc services they do now by this time next year. But yes, customers multihoming is a good thing(tm) for other reasons outlined. And putting all your eggs in one basket -- be it a large and stable telco, or a small DSL aggregator of questionable clue and financial stability -- is never wise, even if it will save you some coin. And at the end of the day, either our IP providers' racks have power, or they don't; either their cross-connects are live, or they're cut with a razor blade...
At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly cheap and getting cheaper), more RAM in the routers is a quick answer. Router clusters are another answer, and faster CPUs are yet another.
Throwing more RAM and CPU into our routers (assuming for a moment that they're most certainly all Linux PC's running Zebra) is not the solution you're looking for; the problem of RIB processing still remains. Getting a forwarding table requires extracting data from the RIB, and this is the problem, because RIBs are very large and active, and are being accessed by lots of reading and writing processes. RIB processing is substantial, and is only getting worse.
If the IETF is being at all effective, that should start now and finish sometime next year, so that we can start the 5-year technology roll-out cycle.
Roeland, The IETF is eagerly awaiting your solution. Send code. See Tony Li's presentation at the Atlanta NANOG on why this solution of jamming RAM and CPU into boxes is not a long term viable answer: <http://www.nanog.org/mtg-0102/witt.html> In short, state growth at each level must be constrained and must not outstrip Moore's law, and to be viable in an economic sense, it must lag behind Moore's law. Things that cause heartache normally involve memory bandwidth from CPU to RIB memory when you need to spend a whole lot of time walking tables as an ever larger percentage of your tables slosh around like yo yos.
should either have his lips perma-bonded together, or have the lower part of his face covered in duct tape. Maybe then, he can resist the urge to chew on his feet.
Hmm, always a good idea. -adam
participants (28)
-
Adam Rothschild -
Alex Bligh -
Andreas Plesner Jacobsen - Tiscali -
bmanning＠vacation.karoshi.com -
Brian Whalen -
Charles Sprickman -
Christopher A. Woodfield -
Clayton Fiske -
Daniel Golding -
Daniel Hagerty -
David Schwartz -
Dmitri Krioukov -
Hal Snyder -
Henry Yen -
Howard C. Berkowitz -
Iljitsch van Beijnum -
Joe Abley -
John Fraizer -
Leo Bicknell -
Mark Radabaugh -
Mark Radabaugh - Amplex
-
Patrick Greenwell -
Paul Schultz -
Randy Bush -
RJ Atkinson -
Roeland Meyer -
Steve Noble -
Valdis.Kletnieks＠vt.edu