- Test - lists.nanog.org

How to achieve application reliability
by Sean Donelan 05 Dec '99

05 Dec '99

On Sat, 04 December 1999, James Smith wrote: > The unfortunate reality is that there are a lot of businesses that need > 99.99% reliability and uptime, but aren't big enough to get a /19. > > My previous company was a credit card processing gateway. If they went > down, their customers were screwed. But they hadn't even used a Class C, > so they weren't eligible for a /19 or /20 from ARIN. > > My point is that the current requirement that a network must have a large > chunck of IP space to be multi-homed is not ideal. According to the > status quo, while an e-commerce company such as a credit card processor > may be big in the business world and worth millions, but insignificant on > the Net and left vulnerable because it can't be multi-homed. Sigh, when you have a hammer everything looks like a nail. There are several different ways to achieve 99.99% application reliability which do not require 99.99% network reliability. In your credit card application, the keyword I see is "gateway." This implies there is already some seperation between the front-end and a back-end application. One method to improve application availablility is have multiple gateways spread around on different networks, instead of depending on a single gateway being multi-homed. Clients could find a working gateway in several different ways, pre-configured addresses, DNS and multiple A records, an application specific discovery protocol. "Its only a small matter of programming." This works best for applications with very small address requirements, such as your credit card company which wouldn't qualify for a /19 or /20 from ARIN. It doesn't make sense for larger address use applications, since it essentially requires addresses be duplicated N times. While this lowers demand on routing table entries, it increases demand for addresses. Depending on which one people think we will run out of first, will change your point of view. Pick your trade-off.

2 1

RE: Long Prefix Redundancy (Was: Verio Decides what parts of the internet to drop)
by Derrick Bennett 05 Dec '99

05 Dec '99

Recently one of my customers was deciding between Co-Location at a major provider and an in-house solution. Now most people will point to cost as a factor but in this decision it was one of the last factors. The major factors were of security, systems, functionality and administration. Without going into all the why's, they made the decision to stay in house. Are we moving towards a Net where you either have to be a big network or be housed at a big network ? How does this help in the theories of diversity and global reach. What happens when we move to IPV6 when every coffee pot in the world has an address and most people have their own network ? Now I know I don't have the answers but I do answer the calls when someone in northern alaska can't get to the web site. Are we to the point where major ISP's can now force us to co-locate at their facilities because of routing rules ? Also how does this impact other countries as more routes and circuits show up worldwide ? I am just wondering how this can get better as the route tables keep growing. Is this a topic for the next nanog :) Derrick P.S. I apologize for letting my last email go out in HTML. -----Original Message----- From: Dana Hudes [mailto:dhudes@panix.com] Sent: Saturday, December 04, 1999 6:51 PM To: Derrick Bennett; nanog(a)merit.edu Subject: Re: Long Prefix Redundancy (Was: Verio Decides what parts of the internet to drop) The pressure is on to use co-location service only from Big Players. Indeed, remember the big fight over Exodus peering arrangements? Someone (GTE?) decided that Exodus should pay them for transit and pulled peering. since no other large network pulled such stunt the result was that GTE customers were inconvenienced more than Exodus customers. The message is loud and clear. If you want your server farm to have good access, put it in a good collocation facility run by a very large provider who has good redundancy not only of their network as a whole but of their colo facility (a co-lo facility with only one WAN circuit does not have good redundancy even if the LAN is exceedingly good and fault-tolerant etc.). Dana ----- Original Message ----- From: Derrick Bennett To: 'nanog(a)merit.edu' Sent: Saturday, December 04, 1999 8:09 PM Subject: RE: Long Prefix Redundancy (Was: Verio Decides what parts of the internet to drop) Since we are all here at this point I would like to ask some questions on what should be done for the small companies. I have setup several /24's with various ISP's and have gotten them multi-homed with secondary ISP's, setup BGP and overall things work relatively well. Now I have always been able to go to some of the route servers and looking glass sites and see my annoucements making it to several providers. But I have no way of knowing that every ISP is accepting these routes and I have always beleived that they weren't anyway. Now through all this many people have asked the same question I am asking. Companies that are being responsible and only occuping a single class C still need redundancy and to me this is what BGP was meant to do. What does the nanog community in general think should be done to help this growing group of customers ? I never remember reading a FAQ anywhere that said only large networks should get the redundancy features that have been built into the Net. And to answer the other point many of my customers would not mind paying a fee to make their routes known. I would rather pay for proper routing then pay for a /19 and waste space. Derrick > -----Original Message----- > From: James Smith [mailto:jsmith@dxstorm.com] > Sent: Saturday, December 04, 1999 4:21 PM > To: Travis Pugh > Cc: Alex P. Rudnev; nanog(a)merit.edu > Subject: Re: Verio Decides what parts of the internet to drop > > > > The unfortunate reality is that there are a lot of businesses > that need > 99.99% reliability and uptime, but aren't big enough to get a /19. > > My previous company was a credit card processing gateway. If > they went > down, their customers were screwed. But they hadn't even > used a Class C, > so they weren't eligible for a /19 or /20 from ARIN. > > My point is that the current requirement that a network must > have a large > chunck of IP space to be multi-homed is not ideal. According to the > status quo, while an e-commerce company such as a credit card > processor > may be big in the business world and worth millions, but > insignificant on > the Net and left vulnerable because it can't be multi-homed. > > > -- > James Smith, CCNA > Network/System Administrator > DXSTORM.COM > > http://www.dxstorm.com/ > > DXSTORM Inc. > 2140 Winston Park Drive, Suite 203 > Oakville, ON, CA L6H 5V5 > Tel: 905-829-3389 (email preferred) > Fax: 905-829-5692 > 1-877-DXSTORM (1-877-397-8676) > > On Sat, 4 Dec 1999, Travis Pugh wrote: > > > > > I've been lurking and looking at this conversation too long > ... my head is > > spinning. Alex says there are many reasons causing people > to announce B > > nets with short prefixes, and he is entirely right. The > primary one would > > be that a client, by some inexplicable reasoning, expects > their Internet > > service to be up and running reliably at least 95% of the time. > > > > The disturbing message I have been able to glean from this > thread is that: > > > > - If you need reliability, get a /19 > > - If you are a small customer, using only a /24 for > connectivity (and thus > > helping to slow depletion) you are not BIG enough to expect > multi-path > > reliability into your network > > - If you are a big provider, not only do you not have to provide a > > consistent level of service to your customers, but you are > free to block > > them (and anyone else from other providers) arbitrarily > when they spend a > > good deal of money to augment your service with someone else's > > > > The gist of the conversation, IMO, is that customers can't > have reliability > > with one provider, but they will be blocked from having > reliability through > > multiple providers if their addresses happen to be in the > "wrong" space. > > Something's wrong with that. > > > > Cheers. > > > > Travis > > Eeeevillll consultant > > > > ----- Original Message ----- > > From: Alex P. Rudnev <alex(a)virgin.relcom.eu.net> > > To: Randy Bush <rbush(a)bainbridge.verio.net> > > Cc: <doug(a)safeport.com>; <nanog(a)merit.edu> > > Sent: Saturday, December 04, 1999 5:08 PM > > Subject: Re: Verio Decides what parts of the internet to drop > > > > > > > > > > > > > It should be your problem. You simply loss the part of > connectivity... > > > > > > The real world is more complex than you drawn below. > There is many reasons > > > causing people to announce class-B networks with the > short prefixes. > > > > > > > > > > > > > > > > > > On Thu, 2 Dec 1999, Randy Bush wrote: > > > > > > > Date: Thu, 02 Dec 1999 13:00:17 -0800 > > > > From: Randy Bush <rbush(a)bainbridge.verio.net> > > > > To: doug(a)safeport.com > > > > Cc: nanog(a)merit.edu > > > > Subject: Re: Verio Decides what parts of the internet to drop > > > > > > > > > > > > > Apparently for their convenience Verio has decided > what parts of the > > > > > Internet I can get to. > > > > > > > > verio does not accept from peers announcements of > prefixes in classic b > > > > space longer than the allocations of the regional registries. > > > > > > > > we believe our customers and the internet as a whole > will be less > > > > inconvenienced by our not listening to sub-allocation > prefixes than to > > have > > > > major portions of the network down as has happened in > the past. some > > here > > > > may remember the 129/8 disaster which took significant > portions of the > > net > > > > down for up to two days. > > > > > > > > the routing databases are not great, and many routers > can not handle > > ACLs > > > > big enough to allow a large to irr filter large peers. > and some large > > peers > > > > do not register routes. > > > > > > > > so we and others filter at allocation boundaries and > have for a long > > time. > > > > we assure you we do not do it without serious > consideration or to > > torture > > > > nanog readers. > > > > > > > > > With no notification. > > > > > > > > verio's policy has been constant and public. > > > > > > > > randy > > > > > > > > > > > > > > Aleksei Roudnev, > > > (+1 415) 585-3489 /San Francisco CA/ > > > > > > > > > > > > > >

1 0

Re: Verio Decides what parts of the internet to drop
by Sean Donelan 04 Dec '99

04 Dec '99

On Sat, 04 December 1999, "Alex P. Rudnev" wrote: > It should be your problem. You simply loss the part of connectivity... > > The real world is more complex than you drawn below. There is many reasons > causing people to announce class-B networks with the short prefixes. Can you give a concrete example? In most of the cases I've seen the people wanting to break up an class-B network either because 1) they don't want to return the class-b network to ARIN and get two or more appropriately sized blocks, or 2) their upstream provider won't aggregate announcements from multiple connections, 3) they made a mistake and announced their IGRP subnets via BGP.

1 0

Re: Verio Decides what parts of the internet to drop
by Sean Donelan 04 Dec '99

04 Dec '99

On Sat, 04 December 1999, smd(a)clock.org wrote: > Peers and customers are currently indistinguishable. > > A peer is simply a customer who receives limited connectivity, > usually constrained by BGP announcement filtering in both directions, > for a heavy discount, sometimes as much as 100% off normal pricing. > > A supplier, on the other hand, is someone who sends you a bill, > even if that bill is hugely discounted, with the expectation that if > it is not paid, the connectivity offered as a service will be terminated. I don't understand your "other hand." Using your logic, not only are peers and customers indistinguishable, but peers and suppliers are also indistinguishable. A customer, on the other hand, is someone who receives your bill, even if that bill is hugely discounted, with the expectation that if it is not paid, the connectivity received as a service will be terminated. A peer is simply a supplier who gives a limited selection of connectivity, usually constrained by BGP announcement filtering, for a heavy discount, sometimes as much as 100% off normal pricing. The problem with equating "peer" with either customer or supplier is you can never figure out who is the customer and who is the supplier. If I send you a bill every month for $0.00, does that make me the supplier and you the customer? To make things even more confusing, there are usually additional requirements peers must comply with, that neither customers nor suppliers do. Why do you think the lawyers go cross-eyed everytime they try to understand a peering agreement.

1 0

RE: Verio Decides what parts of the internet to drop
by smd＠clock.org 04 Dec '99

04 Dec '99

| If filter policies like Sprint's and Verio's really are common among the | big backbone providers, that would seem to make it relatively pointless to | attempt to multi-home with provider supplied IP space. We have a customer | interested in multihoming for reliability, but they use so little IP | space, even assigning them a /24 would be a stretch. Please see RFC 2260. http://www.faqs.org/rfcs/rfc2260.html Sean.

2 1

Re: Verio Decides what parts of the internet to drop
by Sean Donelan 04 Dec '99

04 Dec '99

On Fri, 03 December 1999, Tony Li wrote: > I was not and am not suggesting that anyone stop all filtering. I am > suggesting that a sane prefix settlement scheme would allow us to dispense > with the filtering policies that are currently in place and would allow the > backbone to globally distribute any prefix, regardless of prefix length, if > only the originator has paid enough money and informed people first. You > want to inject a /32? Go right ahead. Send your check to your provider > and it can be made to happen. Such a payment scheme has always existed. The provider with the most agressive filtering policy has always announced many prefixes which they wouldn't accept if the networks were customers of a different provider. Just make your checks out to all the providers you want to reach, and they'll each be happy to install a seperate circuit for your network. It worked for tymnet, telenet and compuserve. In today's Internet a difficult problem is figuring out if they are announcing a /32 accidently, for a dumb reason or for a good reason. Because my upstream provider is too dumb to aggregate isn't a good reason.

1 0

None
by Charles E. Yow, Esq. 04 Dec '99

04 Dec '99

On December 2, 1999 MCI/Worldcom had another outage in Southern Mississippi lasting 9 hours, shutting down local ISPs, however the MCI net in the same are was functioning without difficulty, how can I find if they re-routed their users. Charles Yow

1 0

Re: Verio Decides what parts of the internet to drop
by smd＠clock.org 04 Dec '99

04 Dec '99

| Great idea, but charges should apply to _peers_, not customers. Peers and customers are currently indistinguishable. A peer is simply a customer who receives limited connectivity, usually constrained by BGP announcement filtering in both directions, for a heavy discount, sometimes as much as 100% off normal pricing. A supplier, on the other hand, is someone who sends you a bill, even if that bill is hugely discounted, with the expectation that if it is not paid, the connectivity offered as a service will be terminated. This taxonomy is convenient in that it leaves one with a small grey area wherein neither party sends the other a bill, and neither party has the right to demand that service continues for a particular amount of time. | Charging customers for announces prefixes merely creates an incentive | for backbone operators to announce more routes and, correspondingly, | collect more money. If network X is sending network Y too-long prefixes, or too many prefixes, network X may choose to filter them, or require that they be aggregated. A customer paying a larger amount of money is likelier to have this demand met than a customer with a very steep discount. A supplier, on the other hand, may choose to increase the bill when faced with a customer who sends inappropriate prefixes. In the grey area, who knows? So far the only answers there have been inbound filtering and proxy aggregation. Sean.

1 0

Re: Verio Decides what parts of the internet to drop
by smd＠clock.org 04 Dec '99

04 Dec '99

| Now I don't claim to be a policy wonk and I don't have the | slightest idea of how to make this equitable and fair for all, but I do | know that this would result in an outcome that would give us routing tables | far smaller than our current 67k entries. It doesn't need to be equitable and fair to all; the fact is that I consider my routing table slots to be a scarce resource, and I will conserve that resource. Filtering is one approach; a step towards your approach is relaxing filters for people willing to pay me money to do so. I am sure that if someone with a too-long prefix went to a filtering provider and offered a (probably small) fee, a permanent hole in the inbound filters would be made. We arrive at your approach when we have the ability for someone with a too-long prefix to find every provider who is filtering out the prefix, and negotiate some sort of deal which ends up with a modification to their local filter list. This is a bit unwieldy, since in principle, every routing domain in the Internet might put up filters, and while it is true that perhaps not all of them are someone a person with a too-long prefix would want to talk to at any price greater than $0, a large set will be worth more. Several thousand negotiations (or even several hundred, or even several dozen, and possibly just several) likely will dissuade most people from trying to use a too-long prefix the first place. People with hardcore reasons for using a too-long prefix will probably be willing to pay a fee to an agent able to broker cheapest-possible access to the routing slots in the networks that are smart enough to sell them. As with any market negotiations, some users of a too-long prefix will get a better deal than others. Likewise, some networks can demand higher prices than others. Right now, there are only two known prices for access to routing slots by holders of any prefix of any length: $0 and $infinity. Unfortunately, people on NANOG are much more likely to jump up and down and scream and play politics and whine that THEIR long prefixes are so vitally important that nobody should charge them money for permitting them to occupy routing slots everywhere (because it is against the spirit of the Internet or something like that), than to negotiate an actual price less than $infinity simply by contacting the filtering provider(s) and making an initial offer (or asking them to do so). Your proposal likely will never fly while people in the industry remain hostilely unpragmatic and opposed to free market forces. However, should that change, there are fiddly little details which would have to be worked out; the ugliest of which would be a case where a provider which filters is willing to relax the filter-list in exchange for a small fee, but _it's_ provider is not (or demands a fee the originator is not willing to pay). Another take on this is to consider a global transit network and a national or regional transit network, each of which charges a small price for relaxing a filter against too-long prefixes. If the contract with the global transit network expires, and that GTN is the only direction the national network sees the too-long prefix, what then? A practical technical solution to this would allow "intermediate" backbones to enter into the game of selling routing slots in their networks, no matter what the "top tier" backbones do. | The correlation with route flap should be re-examined. I suspect that this | is no longer a driving force and is more than adequately compensated for by | having flap damping parameters that scale geometrically with the prefix | length. I agree that it should be re-examined, and I have the same suspicion. I believe the problem now is dealing with huge numbers of prefixes (thanks to the trend towards ever smaller networks multihoming) and their dynamism over a longer term than flap-dampening code considers. Sean.

1 0

Filter Policies (was: Re: Verio Decides what parts of the internet to drop)
by Jan Ahrent Czmok 04 Dec '99

04 Dec '99

Hello! IMHO, i also propose to have a clear discussion about some issues which came into my mind when reading all this mails. The next NANOG might be really a good place for this issue. There are some unanswered things: - optimize the Routing Table (e.g. how to come to an agreement with even the largest isps but also including smaller ones) - recent discussed Authorization of Routes and validation - how we all together can get rid of the swamp space (e.g. it MUST the possible somehow) - hints and tips and coordination of filter policies. But these are just my .5 cents Jan

1 0