- Test - lists.nanog.org

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

Re: filtering long prefixes
by Guy Middleton 25 Sep '95

25 Sep '95

> From: Sean Doran <smd(a)icp.net> > Date: Thu, 21 Sep 1995 18:58:02 -0400 > > Yup, 206.12/16 is the first area that jumped out at me after > noting that many /19s and longer under 206/8 can easily be aggregated > under /16s or better. > > Is Herb Kugel still the IP registrar for Canada? Yes, he is. I have copied the last couple of messages to him, in case he has not seen them yet.

1 0

Internic Reference documents jump point established
by sob＠academ.com 25 Sep '95

25 Sep '95

Someone suggested to me that creating a page of links to interesting InterNIC documents might prove useful. This page has been created at the following URL: http://www.academ.com/internic. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: 206.82.160.0/22
by Guy Middleton 25 Sep '95

25 Sep '95

> Ummm, no. RIPE-NCC and APNIC also assign address space as regional > registries, CANET, JPNIC, KRNIC, and AUNIC/Telstra assign space as > national registries. One might claim the IANA has the ultimate > responsibility regarding address space, but this is somewhat > irrelevant to this discussion. A minor clarification: CANET does not run the Canadian IP registry; it is run by the University of Toronto. CANET does run a route registry for CANET customers.

1 0

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

25 Sep '95

From: Tony Li <tli(a)cisco.com> > 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 A global charging scheme implies that there is a centralized, global charging authority. ... What MAY fly, however, is if individual backbones charge for advertisements as well as bandwidth. Ah, I wasn't clear; I was not proposing that this charging be done through any centralized authority. My mental model was much more like your latter thought; individual ISP's would charge for carrying routes, so it would be distributed and decentralized. There are lots of problems you have to work, through, though (see below). Mind, I'm not saying that I'm positive that charging for routes is a *practical* or *desireable* business strategy (there are clearly all sorts of problems). Some sort of cooperative effort to keep routing table sizes down might be more effective overall (i.e. higher cost/benefit ratio) than charging (which is going to have a lot of administrative overhead). However, we might not be able to make that work, in which case charging is the ultimate fallback; having a feedback loop from consumption of resources (routing table entries) to consumers of them is an industrial-strength approach to solving the problem. This would be charged back through regional ISPs, who would decide which backbones to connect to and charge back to their respective customers. Right, your charge would effecitively be related to the scope over which the advertisment was seen, since more the ISP's that carried it -> a bigger total charge. However, there are lots of niggling little problems you have to work out. Here are a few. ISP's cannot charge a flat price per route, since it's not clear that more $$$ will instantly translate into more route-carrying capacity. Set the $$$/route too low, and people will just pay, and the ISP won't have the capaccity. The fact is they have a limited capacity for routes, so there has to be a price curve to discourage further routes as an ISP nears capacity. This will ensure that route resources get allocated to the people who need them the most -> can make best use of them. Even if ISP's do charge a flat price, on a first-come first-served basis, all that will do is create a seceondary market in routes for that ISP; i.e. windfall profits for some, etc. Better would be a "treasury auction" type system. All this is a lot of work, I know; maybe the ISP will just go the flat price route and stay out of the secondary market. (Of course, that leads to the ability to manipulate; hold back a few routes, wait till the price peaks, and then leak them out onto the market; etc, etc..) Another concerns the cross-charging; i.e. with two large providers it easy, they both carry lots of routes for each other, so probably it's a wash (i.e. no money changes hands when the dust settles). But what about small providers? Ideally, you'd like small providers who are being "good guys" (i.e. generating only a few routes) to also have a wash, and the ones who are "bad guys" (ie.. generating lots of routes) to have to pay for it. In other words, small providers have to charge the large providers something for carrying their routes through a small scope (the small ISP) which balances what the large ISP's will charge for carrying the small ISP's route(s). However, this model breaks down when you get to the level of customers; nobody is going to pay customers for carrying routes! So, there remain some holes to be closed up there too. What I'm leading to with all this is that yes, we could create a very efficient (in the sense of allocating costs accurately) market for carrying routes, but it would be very inefficient (in terms of the amount of overhead B/S). Which goes back to my comment above, that maybe charging for routes does not make sense in a larger business context. However, not charging for routes implies we have to come up with another way of controlling routing table growth. I'd be delighted to have a serious conversation about the pros and cons of various charging schemes. Maybe charging's a loser, maybe it's not, but if we're going to consider it, let's look at it seriously, not discard it offhand as "politically incorrect" for the 'net, or whatever. Noel

1 0