- Test - lists.nanog.org

Re: Peering in the LA region?!?
by hoodr＠netcom.com 26 Sep '95

26 Sep '95

> Just curious, but after looking around at several sites in LA, I was curious > if ANYONE was actually doing any significant peering in the LA basin? > Currently > we are looking for multiple interconnects down there in the 10mbps/T3 range, > however we can't find anyone... Is anyone interested in using the PacBell/GTE SMDS cloud down there? I'm pretty sure CERFnet has a connection into the cloud already, and ours is on the way. -- Robert Hood hoodr(a)netcom.com 1-408-551-2160 Manager of Network Operations for NETCOM On-line Communications Services, Inc.

1 0

Re: 206.82.160.0/22
by jnc＠ginger.lcs.mit.edu 26 Sep '95

26 Sep '95

From: gih(a)aarnet.edu.au (Geoff Huston) Given the interaction between the costs of renumbering, vs the cost of establishing an entry in the routing tables, vs the cost of dynamic address translation then its not obvious whether pricing policies should apply to address space allocation, routing table entries or both! It's a truism of large-scale system design (in both biology as well as computers :-) that a single mechanism can do two things well at small scales, but not larger ones. This says to me that a pricing policy that attempts to meet a number of goals (e.g. control routing table growth, maximize efficiency of address space usage) by pricing a single thing is just not going to be as effective, overall, at those goals, as a number of separate pricing policies on different resources. (Hmm, maybe that principle above applies to economics as well? Makes sense, economics and biology have close ties...) Of course, two separate mechanisms (or indeed, any at all) are a lot more complexity, administrative overhead, hassle expended in setting policies (look at DNS name charging :-), etc, etc, so you have to step back and ask, overall, if the gains in getting closer to those goals (using either one mechanism or two) are worth what it costs in complexity, etc. None of which is much help in answering the question "should we price none, one, or both". What I suspect is that we will price none until we simply can't go on without charging, which makes sense; the administrative overhead of charging will be a major headache, so the situation will have to be dire to make it worth it. Noel

1 0

Re: 206.82.160.0/22
by gih＠aarnet.edu.au 26 Sep '95

26 Sep '95

At 5:06 PM 26/9/95, David Conrad wrote: >>I'm arguing that economics have to enter the picture for any application >>for IP address space a registry receives. > >See RFC 1744 for more details. Note that option c is theoretically >not available -- according to current and likely future guidelines, >buying/selling of addresses is essentially disallowed, addresses >should be returned to the orgininating registry to be reallocated as >criteria are met. I would be very interested in hearing people's >opinions regarding this aspect of current allocation guidelines. I would observe that option c) happens today - its just that the parties involved don't inform the InterNIC (becuase if you try to undertake the transfer of title the InterNIC simply takes the address space away. The picture is somewhat complex in so far as IP address space has intrinsic value _as long as it is routeable_. Given the interaction between the costs of renumbering, vs the cost of establishing an entry in the routing tables, vs the cost of dynamic address translation then its not obvious whether pricing policies should apply to address space allocation, routing table entries or both!

1 0

Re: 206.82.160.0/22
by Sean Doran 26 Sep '95

26 Sep '95

However, that aside, I think your policy is reasonable, and just hope it helps cover your costs. Sean.

1 0

Re: 206.82.160.0/22
by Sean Doran 26 Sep '95

26 Sep '95

>I would be very interested in hearing people's opions ?regarding this aspect of current allocation guidelines. It's a joke. Moreover, it's a stupid joke that will wreck the value of registries as sources of accurate information. If the contact person or an officer of the contact organization tells me that a prefix is now to be used by another party, whether it's bought or traded or inherited or sold or whatever, I don't care, I'll route it, provided it's aggregatable into something reasonably short. And if the registries don't update to the new contacts, so what? Sean.

1 0

Re: 206.82.160.0/22
by jnc＠ginger.lcs.mit.edu 26 Sep '95

26 Sep '95

From: Nick Williams <nmw(a)haven.ios.com> If a registries' actions or lack thereof hurt someone else's business they may end up being liable in court for it Oh, great, let's put the registries out of business. I mean, who needs the aggravation, and the threat of being sued? I urge registries to consider charging for their address space delegation services This is absolutely not the solution. This still does nothing to slow the growth of the routing tables, which is the *real problem*, &^%!@$*#&^%! I mean, how is it going to stop me moving from provider A to provider B and wanting to take my addresses with me if I had to pay for the addresses? The only charging scheme that I can see working is to charge people for advertising routes, with the charge related to the scope over which the advertisement is seen. That way, there's a direct relationship between the amount of resources consumed, and the amount charged, which is utterly fair. Note that if you have a "fully" "portable" address (i.e. one advertised over a global scope), your monthly bill will go up as the Internet gets larger, under this scheme... If registries can make decent allocation decisions ... then I argue that routing table growth will be curbed and that IPv4 address space utilization effeciency will rise. First, you're talking about two completely separate problems. Let's keep address space utilization out of it for now, OK? Second, even if registries did allocate addresses optimally, what happens when those sites move around, something the registries have no control over? > "Sorry, we are only able to provide you with partial Internet service > at the moment because Sprint doesn't like the addresses we assigned you". It is costly, as the solution is to become a client of Sprint. So, everyone, can we find a solution? That may solve it for Sprint, but suppose you have the same problem with otehr major providers? Do you have to get a link to each of them? When does this cease to become distinguishable (costwise) for charging for routes - actually, the latter would probably be less expensive. Noel

4 3

Re: 204.82.160.0/22 invisible
by Gordon Cook 26 Sep '95

26 Sep '95

Well I know Iaroslavl on the volga is not as far out as alma alty. But almost exactly a year ago I had quite nice telnet connect from their to chicago for four hours one evening. You are able to do what you are doing in part because you are using infrastructure from communications links that western oil companies paid you to build to various siberian oil fields. true? (I visited your offices in Moscow in April of 1992.) The New Yorker wrote these guys up in December 1991. ******************************************************************** Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 The COOK Report on Internet Non Profit. $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate. Site Lic $650 http://www.netaxs.com/~cook <- Subscription Info & COOK Report Index ********************************************************************

1 0

Re: 204.82.160.0/22 invisible
by Kai 26 Sep '95

26 Sep '95

Vadim wrote: >>kai(a)belcom.net >> Ask us about Internet service in the CIS! >> Bringing Internet, where there is none >What a piece of "truth in advertisement". >--vadim >(the guy who coined the word RELCOM if you didn't know). I know very well, Vadim. But wherever I look (outside of say Moscow and St. Petersburg) there is nothing but 19.2K lines connecting entire cities. I wouldn't call that "Internet", but "laggy connectivity, enabling mail and Usenet". A far cry from telnet,ftp,WWW. And the last time I checked, BelCom was serving areas as a turn-key telecommunications carrier that weren't even on Russian (pre-1986) maps, and you had to drive a few 100 miles to get a working phone there, not even talking about one that you can call abroad with. You remember that too well, I guess.

1 0

Re: Request for Comments on a topological address block for N. Calif.
by Sean Doran 25 Sep '95

25 Sep '95

Noel - Your model is one of the many things that gets solved when doing closest-exit routing with external peers. A quick pair of definitions: a customer is someone paying for transit everywhere through a particular bitpipe; an external peer is a non-customer with which one exchanges traffic. For the most part these days, external peers are not generally also customers. So, in the model I mentioned, we effectively have two customers paying to exchange traffic over A, or over A and S. The fact that one single organization is picking up the bill is not really relevant, or necessarily even knowable. The point is that A is being paid for two customer connections, or A and S are each being paid for one customer connection. A and S are external peers. In your model: | Two large carriers, P and Q, are | interconnected at multiple sites, among them X and Y. Let's further suppose | carrier P has two customers, C1 and C2, near X and Y respectively. We'll assume that P and Q are external peers with no customer/provider relationship with respect to X and Y. There are several answers to your questions, depending on routing policy of both parties. I won't do all variations, but here are the simple cases: P does closest-exit routing towards Q; Q takes MEDs to do best-exit routing towards prefixes P announces, or Q uses an advisory line to allow P to specify exit points from Q to P on a per-prefix basis. Since we have destination-only routing in place in the Internet, P could dump traffic for C1 on Q at Y, and Q would route it to X, deliver it to P, which would carry it to C1. Trivial. Seen it happen. It works. However, Q cannot do the reverse to P. If Q dumps traffic for C2 onto P at X, P would dump it right back to Q at X. In short, you get a routing-loop. Example 1: c3->P--->PY-QY--->Q------>QX-PX-->C1 Example 2: PX<-QX<---c4 | \->QX | PX<-/ There are ways in which this can be worked around, for example, by using outgoing routing filters to announce certain networks to P only at C1 or at C2, or by using differing AS paths in the announcements and the like. I imagine that anyone caught doing this deliberately and without explicit permission (and in practice it has been pretty easy to catch) would quickly find themselves with no peering at all, and would just as quickly become a pariah. (Non peers at X and Y could aim static routes too, which is equally ugly, and the way around this on the engineering (as opposed to legal department) front, on top of pariah methods and the fact that there is the return-traffic problem that isn't always trivial to deal with, is to break level-2 connectivity between, say, N and Q at X and Y, or to use various ugly war knobs in people's favourite routers.) If Q voluntarily allows P or N to do this type of long-haul routing through Q's backbone (AS healing and the like), then imho Q is pretty stupid, and not just for the reasons you mention. Also for some of the reasons you touch on, I think that having a customer relationship with anyone at X or Y would also be a silly thing for Q to do. Sean.

1 0

Re: Request for Comments on a topological address block for N. Calif.
by Vadim Antonov 25 Sep '95

25 Sep '95

That is not the new question -- i was trying to obtain the block equal to 8k class Cs a year ago -- unsuccessfully. How about treating Sprint's allocations as allocations for 10 providers in different geographical areas? --vadim Sean, Currently Sprint receives the largest sized CIDR block the InterNIC is permitted to allocate. If you have a requirement for an even larger block than please submit the justification and I will be glad to pass it onto the IANA for approval. Kim Hubbard InterNIC Registry > Unfortunately, the allocations we've been getting haven't > been very big, and so we end up having to introduce things > as long as 17 bits to the world, where we might have only > had to announce /16s and /15s with a larger delegation > from a registry. > > Block Name Total Free Used Free Blocks > Cs Cs 1 2 4 8 16 32 64 128 256 512 1024 > -------------------------------------------------------------------------- > East 2863 233 91% 1 1 1 1 1 > West 2176 51 97% 1 1 1 1 > South 2176 47 97% 1 1 1 1 1 > North 1920 218 88% 1 1 1 1 1 > NorthEast 1408 211 85% 1 1 1 1 1 > SouthWest 768 173 77% 1 1 1 1 1 > NYSERNet 512 129 74% 1 1 > ICM-Atlantic 128 122 4% 1 1 1 1 1 > -------------------------------------------------------------------------- > TOTAL 11951 1184 90% 6 5 2 5 4 5 4 5 > > > So, beacause we are clever and do a mix of provider-based > and geography-based allocation (but it is a mix of both, > with an emphasis on the provider part), we end up with > blocks that are starving, but a single huge allocation that > isn't full enough to have a new large allocation done by the > registry. > > Sean. > >

1 0