September 1995 - Test - lists.nanog.org

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

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

25 Sep '95

Alan - This is an excellent idea, and I shall try to make time tomorrow to explain in easily-understood terms what all this means. Sean.

1 0

Re: 204.82.160.0/22 invisible
by Sean Doran 25 Sep '95

25 Sep '95

Ed - Excellent. Thank-you. Sean. - -- | From ejk(a)nitrous.digex.net Mon Sep 25 01:41:25 1995 | From: Ed Kern <ejk(a)nitrous.digex.net> | To: asp(a)uunet.uu.net (Andrew Partan) | Cc: kai(a)belcom.net (Kai), dorian(a)CIC.Net, avg(a)sprintlink.net, baldwin(a)SDD.COMSAT.COM, bertolini(a)computel.com, concaj(a)belcom.net, donagm(a)belcom.net, | ilya(a)phri.nyu.edu, insc(a)sprintlink.net, ken(a)belcom.net, khalfk(a)belcom.net, ladycom(a)computel.com, nanog(a)MERIT.EDU, noc(a)digex.net, smd(a)sprint.net, | susan.evans(a)SPRINT.SPRINT.COM | Subject: Re: 204.82.160.0/22 invisible | | | Some additions | | | On September 25, you wrote: | > Poking at this futher, Sprint is announcing 204.82.160/22; Digex is | > behind ANS; this route is not in the RADB; and since ANS insists on all | > routes being in the RADB, they are not accepting it, so Digex is not | > seeing it. | | Ive statically nailed up this route to sprintlink, for the week of | this event. It will be removed either when the week is up, or as soon | as sprintlink/sean requests its removal. | | | 206.82.160/22 for the record. | > | > Fix: Either get ANS to not insist on all routes being in the RADB or | > submit an update to the RADB & wait for ANS to regenerate their | > configs. | | While the RADB is flawed (overloaded to the tune of about 30k routes | and not including routes such as this one) I dont think ans is quite | ready to hang it up... | | so those of us who rely on the RADB, or (in my case) rely on transit | provider based on the radb, we'll have to take these one at a time. | | | Hopefully without the "anti-trust, im going to sue you, guess I have | to be the martyr" bullshit. | | > | > Kai: Please don't widly accuse folks before poking into the facts. | > --asp(a)uunet.uu.net (Andrew Partan) | | | and as to this | | >> Correct. I have other networks in 204, so above was a typo. Also correct: | >> he (rather cryptically) said Sprint wouldn't filter outgoing (hence | >> customer-owned) routes, but he encouraged OTHER providers to do it like | >> Sprint: filter incoming routes by the rules anounced: this has the same | >> effect, but now Sean could point at Digex (should they employ such a | >> filter) "I didn't do it, man!"... | | Ill have you know that the filter list im working on looks nothing like | the sprintlink one in any way..least not after I took those ugly comments | out ;) | | Ed | |

1 0

Re: 204.82.160.0/22 invisible
by Sean Doran 25 Sep '95

25 Sep '95

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> - -- | From nanog-request(a)merit.edu Mon Sep 25 01:04:24 1995 | Resent-Date: Mon, 25 Sep 1995 01:03:08 -0400 | From: asp(a)uunet.uu.net (Andrew Partan) | Resent-To: <smd(a)chops.icp.net> | Subject: Re: 204.82.160.0/22 invisible | To: kai(a)belcom.net (Kai) | Cc: dorian(a)CIC.Net, kai(a)belcom.net, avg(a)sprintlink.net, baldwin(a)SDD.COMSAT.COM, bertolini(a)computel.com, concaj(a)belcom.net, donagm(a)belcom.net, | ilya(a)phri.nyu.edu, insc(a)sprintlink.net, ken(a)belcom.net, khalfk(a)belcom.net, ladycom(a)computel.com, nanog(a)MERIT.EDU, noc(a)digex.net, smd(a)icp.net, | smd(a)sprint.net, susan.evans(a)SPRINT.SPRINT.COM | Resent-From: nanog(a)MERIT.EDU | X-Mailing-List: <nanog(a)MERIT.EDU> archive/latest/167 | X-Loop: nanog(a)MERIT.EDU | Resent-Sender: nanog-request(a)MERIT.EDU | | Poking at this futher, Sprint is announcing 204.82.160/22; Digex is | behind ANS; this route is not in the RADB; and since ANS insists on all | routes being in the RADB, they are not accepting it, so Digex is not | seeing it. | | Fix: Either get ANS to not insist on all routes being in the RADB or | submit an update to the RADB & wait for ANS to regenerate their | configs. | | Kai: Please don't widly accuse folks before poking into the facts. | --asp(a)uunet.uu.net (Andrew Partan) | | |

1 0