- NANOG - lists.nanog.org

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 15 Sep '00

15 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 15 Sep '00

15 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

can you fwd this to arin-discuss for me? my mail's not getting there.
by Paul A Vixie 14 Sep '00

14 Sep '00

To: arin-discuss(a)arin.net Subject: Re: guideline for name-based web hosting justification In-reply-to: Your message of "Wed, 13 Sep 2000 11:41:24 EDT." <Pine.BSI.4.20.0009131139140.2436-100000(a)staff.dca.net> Date: Wed, 13 Sep 2000 09:39:55 -0700 From: Paul A Vixie <vixie(a)redpaul.mibh.net> > I have to agree with Mike Horwath. We are looking at what's required to > move from IP- to name-based virtual hosts, and we find that name-based > virtual hosts are really a different product than IP based virtual hosts > -- and along with name-based vhosts comes a whole host of headaches for us > (log processing/IP accounting) and our customers (incompatability with > older browsers). > > I hope that ARIN reconsiders this policy. we (as a community -- the internet) knew that there was an address shortage some years ago. all of the allocation policies, and much technical innovation, over the period of years from "then" to "now" has been influenced by this. some of the people now complaining about the allocation policies have started their web hosting businesses in only the last five years, during which time the need to deploy address-scarcity technology like name-based virtual web hosts was common knowledge. absolutely common knowledge. there's no excuse, either for companies who were doing web hosting before 1995 (who have had time to change their strategies) or for companies who have only done it since 1995 (and who should never have deployed an ignorant strategy), to complain about the current allocation policies. this discussion is starting to remind me of the "freeway sound wall" argument. US101 has existed much longer than some of the residential neighborhoods which have sprouted up alongside it. why the residents of those neighborhoods are complaining about freeway noise and demanding sound walls, just eludes me.

1 0

Re: HR 4445 Reciprocal Compensation
by David Lesher 14 Sep '00

14 Sep '00

Unnamed Administration sources reported that Brett Frankenberger said: > > Real CLECs -- those that try to serve a broad based market, rather than > hack togethor a contrived market that will result in a high ration o > finbound to outbound calls, will do fine in the absence of reciprocal > compensation. Suffice to say, senior communications attorneys disagree with you. If you wish to debate that (non-NANOG) issue, come join the CYBERTELECOM-L list where it's 100% on-topic. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Re: HR 4445 Reciprocal Compensation
by Chip Sharp 14 Sep '00

14 Sep '00

If anyone is interested in the testimony at the last hearing on this (June 22), here is the (long) link. http://com-notes.house.gov/cchear/hearings106.nsf/HearingExpand?OpenView&St… ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org -------------------------------------------------------------------

1 0