September 2000 - Test - lists.nanog.org

Re: Confussion over multi-homing
by Sean Donelan 15 Sep '00

15 Sep '00

On Thu, 14 September 2000, Brantley Jones wrote: > The problem is GETTING a /20 from anybody. We recently tried and could > only get a /23 (being a small start-up). BUT, that /23 is (apparently) > globally routable because of peering agreements with L3 and UUNET. Our /23 > prefix has yet to be filtered by anybody. It could be filtered now. You just won't find out about it until you try to reach a particular site, or they try to reach you. There is no practical way to test if an address is being "globally routed." You could try testing every address in your route table, but there is no assurance your route table is complete.

3 3

HR 4445 Reciprocal Compensation
by William Allen Simpson 15 Sep '00

15 Sep '00

"To exempt from reciprocal compensation requirements telecommunications traffic to the Internet. " Anybody know about this? Seems like it kills payments by ILECS to CLECs for dialups, when the calls are to an ISP. Note, only _TO_ an ISP; folks wanting to provide voice are still required to pay ILECs for traffic _from_ an ISP. Is this the "ILECs put ISPs out of business" act? `(A) IN GENERAL- Notwithstanding subsection (b)(5), after the date of enactment of this paragraph, no local exchange carrier shall be required to make any payment for the transport or termination of telecommunications to the Internet or any provider of Internet access service. `(B) JURISDICTION- Such transport or termination shall be considered interstate communications and subject to the exclusive jurisdiction of the Commission. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

8 8

RE: Confussion over multi-homing
by Roeland M.J. Meyer 15 Sep '00

15 Sep '00

David Lott: Thursday, September 14, 2000 10:34 AM wrote: > First, allow me to state the assumptions that I'm under. I understand > the policy to state that if a business needs to multi-home > and requires > less space than a /20, then they should request this space from their > ISP. I also understand that there are filters at the /20 > boundaries in > order to minimize the size of the routing table. > > Question: Doesn't this break multi-homing for end users that > need less > than a /20? Yep, this has been a topic here before...no real resolution. You didn't really need to prove the case, it has already been proven. The only way that you can do it is to justify a /20 or larger, get portable IP space from ARIN, and make your own peering arrangements with your upstreams. Considering that you will probably burn the best part of the /20 with distributed services, this increases your internal administration costs substantially. What you will have is a very low-density use net-block, but at least you can now multi-home and even have some geographical independence, for multiple-site use. If you have good admins, the whole thing can be folded/collapsed into about 20 physical servers, or less (Lintel boxen keep the costs low too, see: VA-Linux, about two racks). Is this wasteful of IP space? ...absolut! Is this necessary? ...sometimes. If you are building a H-Rel/Hi-Avail/Hi-Secure site(s), you ain't getting there without multi-homing with at least three providers. If you have multiple sites, you can't get there without multi-homing on an ASN that will be advertised (at least a /20, probably a /19). Do I tell clients this? ... absolut! Have I done this for clients? ... Yep, and I ain't saying who for either. --- R O E L A N D M . J . M E Y E R CEO, Morgan Hill Software Company, Inc. Managing Architect Tel: (925)373-3954 Fax: (925)373-9781 http://staff.mhsc.com/rmeyer

3 2

Confussion over multi-homing
by David Lott 15 Sep '00

15 Sep '00

I've read the current policy on ARIN's allocation of space and I must admit that I'm still confused. First, allow me to state the assumptions that I'm under. I understand the policy to state that if a business needs to multi-home and requires less space than a /20, then they should request this space from their ISP. I also understand that there are filters at the /20 boundaries in order to minimize the size of the routing table. Question: Doesn't this break multi-homing for end users that need less than a /20? For example, assume that the end user is connected to two regional ISPs (ISP-A and ISP-B). Neither of which have agreements with each other. However, they do share a common backbone with a national provider we will call ISP-Z. If ISP-Z has filters at /20 for both of the ISPs that it is connected to, then ISP-A address space will be the only space listened to on the ISP-A to ISP-Z link. The same would be true for the ISP-B address space only being listed on the ISP-B to ISP-Z link. This creates a situation where address space from ISP-B would not be advertised through ISP-A and in effect, breaks multi-homing. Consider a remote site attempting to reach the web server at the end user. DNS resolves the address to ISP-B address space. Also assume that the link between the end user and ISP-B is down. As the packet enters the national carrier ISP-Z's network, at some point the router will have to decide to send the pack on. If ISP-B is still advertising the remaining portion of their network (say at the /20 boundary) then ISP-Z will forward the packet to ISP-B. This is normal and proper for a single homed address space. However, if the end user had their own micro allocation, their address space would be advertised to both ISP-A and to ISP-B and in turn to the national carrier. As such, the destination network route would be dropped from the advertisement coming out of ISP-B and the only remaining route would be via ISP-A and the packet would still get there - if the end user had a micro allocation as per previous policy. Also, let us further look a situation where ISP-B is down. When the national carrier detects ISP-B is down it will remove that particular route from it's table. In the old way of doing things with micro allocation to multi-homed end users, ISP-A would advertise the address space from the end user. It is my understanding that under the current policy, ISP-A would have to advertise the address space allocated to the end user from ISP-B. If the address is less than a /20 and if the national carrier is filtering on a /20, wouldn't that cause the update to be dropped and thus not added to the routing table for the national carrier? I guess my confusion could be cleared up if someone could describe how, under the /20 policy, an end user requiring multi-homing and less than a /20 allocation would be able to survive one of their two ISPs going down (remember the AT&T and MCI outages?). Thanks, PS. I have sent this email to the ARIN policy list but have not received any useful responses. -- David Lott VP of Operations MSN Communications (303) 347-8303

3 2

Why did we do CIDR? (RE: Confussion over multi-homing)
by Sean Donelan 15 Sep '00

15 Sep '00

On Thu, 14 September 2000, Paul Froutan wrote: > What you can do is get permission from the ISP that provides you the IPs > (say ISP A) so you can have other ISPs announce your blocks. You also need > to get ISP A to deaggregate your block and announce it separately into the > global BGP table. We did this back in the day and it works fine if the ISP > giving you IPs is somewhat reasonable and helpful. If folks are going to deaggregate the addresses and announce multiple routes anyway, why are we going through the pain of ARIN policies. Wouldn't it be better to allocate the appropriately sized address in the first place?

4 3

2260 Multihoming
by Chandrasekar Ramachandran 14 Sep '00

14 Sep '00

What exactly is/are the reason(s) the mult-homed (to different ISPs) routing strategies suggested by RFC 2260 is not widely deployed (or not deployed at all)? I think there may be some commercial reasons too for this. thanks, Chandra.

1 0

BT suspends service guarantees
by Sean Donelan 14 Sep '00

14 Sep '00

Not North America, but it may affect some North American network operators. Due to the fuel shortages in the UK, British Telecom (BT) has suspended appointments and service guarantees. Customers affected will not be compensated. Emergency repairs will still be made for hospitals, doctors and other emergency services.

1 0

New fire in near Oregon border affects California/Oregon Intertie
by Sean Donelan 14 Sep '00

14 Sep '00

CAISO declares second stage two emergency due to a new fire affecting the Northern California intertie power lines with Oregon. Continued heat exacerbated by a fire that erupted near the Oregon border led to the Stage Two declaration. The fire was reportedly caused when a transmission line that is part of the crucial California Oregon Intertie (COI) sagged into a tree, igniting the fire. Power deliveries headed into California on the path of lines that make up the COI have been cut by several hundred megawatts. Additionally, a total of 3,964 megawatts of power plant units are off line today due to mechanical failure or planned maintenance that could not be postponed.

1 0

RE: Confussion over multi-homing
by Richard Welty 14 Sep '00

14 Sep '00

> Wouldn't one of the ISPs have to advertise a longer prefix? actually, to do it right, both have to advertise the longer prefix -- or more specifically, they have to both make holes in their filters permitting the multi-homed site to advertise them. this is what we're doing in our Troy, NY facility -- we have 2 upstreams, and we have a /24 from one of them, which both of them pass through. richard

2 1

RE: When IPv6 ... if ever?
by smd＠clock.org 14 Sep '00

14 Sep '00

| The bottom-line appears that everyone is waiting for everyone else to | twitch first, then the shoot-out starts. However, no one is all that | interested in twitching. Also, nobody is willing to get shot! The deployment of IPv6 is going to be EXPENSIVE in terms of real opex and probably real capex as well, it IS going to be visible on the bottom line of every ISP on the planet, eroding whatever margins one has. I can't see the deployment of IPv6 *ever* leading to any but the shortest-term revenue upside (if even that), therefore until the entire aggregate gross revenue of transit-providing ISPs up and down the entire food-chain is threatened, nobody will be deploying v6. The only alternative scenario I can think of is the deployment of IPv6 by a large provider who believes it can trigger a huge consolidation by pushing smaller ISPs it is competing with into an expensive deployment through sheer hype. I am inclined to believe that the second thinking is the REAL reason behind the recent announcements by a monopolistic and internationally expanding ISP in Asia that they will do an aggressive IPv6 deployment. | The real question is whom is benefiting from sustaining the current | situation? Everyone who wants cheap, sustainable Internet transit, with the continuation of plummeting prices combined with soaring available bandwidths. Introducing a whole new protocol requiring massive global operational changes is going to push up consumer prices and stall on investment in available bandwidths. There are only so many people and dollars out there, and one or the other is inevitably spread pretty thin in the current market. The scariest thing to an IPv6-Lover is that an early deployment is not to anyone's advantage because untili there is real uptake by a sizable number of ISPs, the exact changes required on the dynamic routing side are simply not obvious, although the fact that the two protocols will run ships in the night is (e.g. www.microsoft.com works just fine with IPv6 but you see a blackhole with IPv4. ftp.cdrom.com's IPv6 path is much slower and lossier from where your customer is than ftp.cdrom.com's IPv4 path. have fun finding and fixing the square of the number of problems you observe now, kids!) In other words, it's all risk and absolutely no reward, and until it really honestly IS impossible to do hacks around the IPv4 shortage, nobody will deploy IPv6. Now, ironically, in the whole IPv6 selection process in the IETF, there were multiple proposals which paid a considerable amount of attention to the problems of partial, incremental deployment at the initial design level. CATNIP in particular was clever, because it provided not just a new packet format (which is all IPv6 did), but also a strategy to transition to practically ANY new packet format, should the initial assumptions about the pervasiveness of IPX and CLNP be wrong (which they were). IPv6's initial assumptions are WRONG (we will die from routing dynamicism long before we die of IPv4 address depletion), and there is NO mechanism whatsoever to abandon the IPv6 packet format even at the primitive level of curiosity-based microdeployment we see now. Who will take the chance of a huge investment in managing IPv6 deployment, when it is not a given that IPv6 really will be the header networks will use after IPv4? We're talking about stranded assets being the only thing one gets for the money... Sean.

4 3