- NANOG - lists.nanog.org

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

Re: 204.82.160.0/22 invisible (fwd)
by Kim Hubbard 25 Sep '95

25 Sep '95

> Kai, As I tried fervently to explain to you when you demanded IP addresses while refusing to complete an ISP template, there is information in the ISP template and the ISP guidelines which is very important to a start up ISP. Part of that information is the paragraph below which deals with the possibility of filtering prefix lengths. You are incorrect when you state the paragraph below is only in the IP template. The InterNIC has done everything we can to inform the public of possible future consequences when receiving addresses directly from the InterNIC. Please read or reread the ISP guidelines (since you officially agreed to abide by those policies in an email message to the InterNIC, I assumed you had already read them). They can be found at ftp://rs.internic.net/ policy/internic/internic-ip-1.txt. Kim Hubbard InterNIC Registry > >Just out of curiosity, why should Internic strap on more asbestos? > > >I thought the following would have been warning enough: > > > ***PLEASE READ THE FOLLOWING INFORMATION PRIOR TO REQUESTING AN > >IP NUMBER FROM THE INTERNIC: > > >Due to technical and implementation constraints on the Internet routing > >system and the possibility of routing overload, certain policies may > >need to be enforced by the major transit providers in order to reduce > >the number of globally advertised routes. These potential policies > >may include setting limits on the size of CIDR prefixes added to the > >routing tables, filtering of non-aggregated routes, etc. Therefore, > >addresses obtained directly from the InterNIC (non-provider-based, > >also known as portable) are not guaranteed to be routable on the Internet. > > this is from the internet-number-template.txt, which wasn't quite the > template I dealt with (I submitted the isp-ip-template.txt), as the > requirements for the assignment were clearly (and stated to the Internic): > a.) portable, as a change in US domestic attachment point(s) is imminent > b.) multi-homed across continents is foreseeable within 3-4 months > c.) they were specifically named as networks that were in turn to be given > out to our customers, and a provider-dependent IP range was not acceptable > > Given these conditions, it was gross neglience if not outright malicious for > the Internic to give us an assignment that, according to obviously previously > aired and announced policy of Sean Doran and others, would not be routed > on major parts of the Internet just days later, a fact that was for sure not > unknown to the IP registry. > > That's enough reason to be cautious and strap on more asbestos for the case > I come back to them about this, I believe. > --- > 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 > >

1 0

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

25 Sep '95

| Right now, larger ISPs aren't getting large | blocks, and they are allocating things in non-contiguous non-growable | blocks, neither of which is good. Nothing is being done to organize | topological assignments at all, which is seriously not good. If some registry were to give me a /8, I would carve that up right now into ten chunks (one per SprintLink POP as of a couple weeks from now) and subdivide those to take into account possible growth into new cities before the current allocations to end users were exhausted, and allow for unexpectedly heavy or unexpectedly light allocations to customers from those prefixes. However, those ten chunks would be the only individual prefixes announced out of AS1239 to the rest of the world, in the entire /8. Some parts of the world would even see the /8 and not the ten individual per-POP prefixes. This is what is done now with smaller chunks of address space: Block Name IP Addresses ------------------------------------------------------------------------------- East 198.67.0/17 198.69/16 199.0/16 204.117/16 204.180/16 204.183/16 204.215/16 205.160/15 205.244/15 206.105/16 West 198.68/16 199.2/16 204.94/16 204.119/16 204.182/16 204.212/16 205.162/15 206.107.128/17 South 199.1/16 204.96/16 204.181/16 204.214/16 204.251/16 205.240/15 206.61.0/17 206.104/16 North 198.70/16 199.3/16 204.95/16 204.120/16 204.248/16 205.242/15 206.106/17 NorthEast 204.97/16 204.213/16 204.249/16 205.246/15 206.106.128/17 SouthWest 204.118/16 204.250/16 206.61.128/17 206.107.0/17 ICM-Atlantic 198.67.128/17 NYSERNet 204.168/16 205.232/16 and with a best-fit algorithm for allocation to customers (all done in nifty software written by Vadim Antonov), we do pretty well in terms of site-aggregation and keeping lots of subnets of these out of our backbones. 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.

4 3

Almaty lives...Re: 204.82.160.0/22 invisible - NOT!
by sgoldste＠nsf.gov 25 Sep '95

25 Sep '95

At 11:33 PM 9/24/95, Kai wrote: ... >The Almaty NATO networking conference is IN SESSION (trace to 206.82.161.1 >if you can ), I think I can; I know I can: 1 gw.cise.nsf.gov (128.150.55.1) 5 ms 5 ms 5 ms 2 wtn6-nsf-c1.sura.net (192.221.39.13) 12 ms 5 ms 6 ms 3 wtn9-wtn6-ce.sura.net (128.167.26.9) 7 ms 14 ms 5 ms 4 wtn8-wtn9-cf.sura.net (128.167.7.8) 6 ms 5 ms 7 ms 5 cpe1-fddi1.Washington.mci.net (128.167.7.100) 8 ms 6 ms 5 ms 6 border1-hssi1-0.Washington.mci.net (204.70.56.5) 6 ms 6 ms 6 ms 7 core-fddi-0.Washington.mci.net (204.70.2.1) 6 ms 6 ms 6 ms 8 core-hssi-3.NewYork.mci.net (204.70.1.6) 11 ms 11 ms 11 ms 9 border2-fddi-0.NewYork.mci.net (204.70.3.18) 11 ms 11 ms 11 ms 10 sprint-nap.NewYork.mci.net (204.70.45.6) 15 ms 102 ms 15 ms 11 sl-pen-2-F4/0.sprintlink.net (192.157.69.9) 42 ms 36 ms 36 ms 12 sl-pen-4-F0/0.sprintlink.net (144.228.60.4) 18 ms 13 ms 12 ms 13 sl-computel-1-S0-T1.sprintlink.net (144.228.64.74) 21 ms 20 ms 19 ms 14 gate.belcom.net (204.97.218.1) 24 ms 22 ms 23 ms 15 ny-msw-256k.belcom.net (204.97.218.4) 31 ms 23 ms 24 ms 16 gate.moscow.belcom.net (206.82.160.1) 173 ms 174 ms 172 ms 17 204.97.219.1 (204.97.219.1) 190 ms 192 ms 188 ms 18 gate.almaty.belcom.net (206.82.161.1) 955 ms 951 ms * --SG ================================================================ Steven N. Goldstein Program Director, Interagency & International Networking Coordination Div. of Networking and Communications Research & Infrastructure National Science Foundation 4201 Wilson Boulevard, Room 1175 Arlington, VA 22230 Tel: +1-703-306-1949 (Extension 1119) FAX: +1-703-306-0621 sgoldste(a)NSF.GOV ================================================================

1 0

Re: 204.82.160.0/22 invisible (fwd)
by Kai 25 Sep '95

25 Sep '95

>Just out of curiosity, why should Internic strap on more asbestos? >I thought the following would have been warning enough: > ***PLEASE READ THE FOLLOWING INFORMATION PRIOR TO REQUESTING AN >IP NUMBER FROM THE INTERNIC: >Due to technical and implementation constraints on the Internet routing >system and the possibility of routing overload, certain policies may >need to be enforced by the major transit providers in order to reduce >the number of globally advertised routes. These potential policies >may include setting limits on the size of CIDR prefixes added to the >routing tables, filtering of non-aggregated routes, etc. Therefore, >addresses obtained directly from the InterNIC (non-provider-based, >also known as portable) are not guaranteed to be routable on the Internet. this is from the internet-number-template.txt, which wasn't quite the template I dealt with (I submitted the isp-ip-template.txt), as the requirements for the assignment were clearly (and stated to the Internic): a.) portable, as a change in US domestic attachment point(s) is imminent b.) multi-homed across continents is foreseeable within 3-4 months c.) they were specifically named as networks that were in turn to be given out to our customers, and a provider-dependent IP range was not acceptable Given these conditions, it was gross neglience if not outright malicious for the Internic to give us an assignment that, according to obviously previously aired and announced policy of Sean Doran and others, would not be routed on major parts of the Internet just days later, a fact that was for sure not unknown to the IP registry. That's enough reason to be cautious and strap on more asbestos for the case I come back to them about this, I believe. --- 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

1 0

Re: 204.82.160.0/22 invisible (fwd)
by Kai 25 Sep '95

25 Sep '95

Sean Doran wrote: >Thank-you Andrew. That matches my diagnosis. >Kai: computel, our customer, should be able to help you >prepare an entry for the RADB; failing that, please >feel free to turn to noc(a)ans.net or engineer(a)sprint.net >for assistance in updating the RADB so that your prefix >is heard by ANS. >See, ANS has an inbound route-filter too... and it's MUCH older than Sprint's. > Sean. >- -- >Sean Doran <smd(a)sprint.net> >- -- In lieu of Computel knowing what the RADB is, I will handle the RADB entry myself, if I don't decide to recycle the assignment altogether and start from scratch, which is likely by now, after analyzing and evaluating the situation a bit more. The Internic should strap on more asbestos now. Is it preferable for Sprint to announce/act under my (future) ASN rather than take the route into one of their own ASNs ? Computel is kinda a like dark tunnel between us at this time... THANKS to all for the response and fix for now. bye, Kai "don't filter my route" Schlichting ps: some NANOG readers wrote back that my route is looping overseas: yes, there is some trouble this hour...the evil of default routes. --- 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

2 1