- Test - lists.nanog.org

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

Re: 204.82.160.0/22 invisible
by Vadim Antonov 25 Sep '95

25 Sep '95

>Kai Schlichting >Internet Project Manager, BelCom, Inc. >515 Madison Ave Suite 2100 >NY,NY 10022 >212-705-9500 (voice) >212-755-0864 (fax) >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).

1 0

Re: Request for Comments on a topological address block for N. Calif.
by jnc＠ginger.lcs.mit.edu 25 Sep '95

25 Sep '95

From: Sean Doran <smd(a)cesium.clock.org> > If, say, mountainview.net ... branched out to Miami, and bought another > Alternet ISP T-1 connection out there, they would then be getting free > transit between them. I don't see that this is a problem. After all, if they bought two AlterNet connections, isn't being able to send traffic across AlterNet what they're *paying* for? Hmm. But what about the follwing situation. 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. What's to stop carrier P taking trafic from C1, giving it to Q at X, and getting it back at Y, and thence taking it to C2? That way, P (presumably) gets paid for carrying the traffic around, but Q does all the long-haul work. Yes, P has to pay Q for large enough access pipes, but isn't Q's charging model assuming that all customers have traffic profiles in which data, on average, travels approximately equal distances (since I assume it costs more money to ship 1 Mbit/sec 3K miles than it does 10 miles)? So, if a customer of Q can arrange to have all their data travel a long way, they can come out ahead of the game, i.e. with lower cost than actual cost. If so, I'd assume P can pay Q's access fess, and still come out ahead, which seems to me to be rather like getting something for nothing... Now, maybe I'm confused about the true costs? Noel

2 1

Re: Request for Comments on a topological address block for N. Calif.
by jnc＠ginger.lcs.mit.edu 25 Sep '95

25 Sep '95

From: George Herbert <gherbert(a)crl.com> You broke my critical assumption, which is that we're going to draw the "39/8" boundary around northern california. Exactly! The whole point of geographic addressing (which is what you're proposing, effectively) is that it assumes that stuff which is inside a given geographic entity, and addressed as such, is fully interconnected when it comes to the 'net's actual connectivity. I.e. you can draw a boundary around a contiguous chunk of the network, and have that boundary contain everything that's in a geographic area. Break that assumption, and all of a sudden things don't work so well anymore. Look, we have two choices: we can make the addressing follow the 'net's topology, or we can make the 'net's topology follow the addressing. They *have* to be connected, *we* only get to chose which comes first. Making the addresses follow the topology means that we have a lot more flexibility to make the connectivity respond to traffic patterns, policy demands, etc, etc; the addresses then trail along behind. If the topology has to follow the addressing, you *can't* have the topology be completely free to respond to user's needs. To me, this choice is a no-brainer. The right solution may not be this, it may end up being ... allocate larger blocks to backbone providers, and having backbone providers not fuss too much about small to midlevel ISPs going multihomed, and having backbone providers allocate space for growth for small to midlevel ISPs. But, at this point, that's not happening either. Well, the Right Solution to a lot of these problems (but not renumbering of routing-names as the topology changes, that will always be with us) is variable length routing-names which grow from the bottom up, but that solution isn't available in the system we have now. So, let's look at what we do have. Within those limits, your proposal above sounds like a good start, although perhaps there are problems that ithers with more operational experience than I can see. If not, how can we make it happen? Noel

2 1