- Test - lists.nanog.org

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

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

25 Sep '95

Ahem. We are doing no outbound filtering, as noted earlier, so if you are announcing the /20 to Sprint, and DIGEX isn't hearing it, then either DIGEX or ANS is doing something odd routing-wise, and it should be debugged via the Sprint INSC and not the Sprint legal department. Sean.

1 0

Re: 204.82.160.0/22 invisible
by Ed Kern 25 Sep '95

25 Sep '95

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