- Test - lists.nanog.org

OFF TOPIC: Pre-NANOG Activities
by Derek Elder 23 Jan '99

23 Jan '99

Are there any groups getting together on Saturday to do anything interesting such as going skiing? D E R E K E L D E R Associate Partner, CCIE# 4048 __________________________________________ USWeb/CKS http://www.uswebcks.com/ 120 Wood Ave, Suite 300 Iselin, NJ 08830 ph: 732-632-2778 fax: 732-321-3809

2 1

FW: Concert Network Scheduled Maintenance - UK (Subnet 4)
by Regan, Sharon 22 Jan '99

22 Jan '99

-----Original Message----- From: BrownLJ(a)stentor.ca [mailto:BrownLJ@stentor.ca] Sent: Friday, January 22, 1999 4:03 PM To: Regan, Sharon Cc: GreenKB(a)stentor.ca; GodardD(a)stentor.ca; WongR(a)stentor.ca; SavardCR(a)stentor.ca; MenardPA(a)stentor.ca; McfetridgeM(a)stentor.ca; FournierLC(a)stentor.ca; SchroederJP(a)stentor.ca; ShurtliffMJ(a)stentor.ca; LockeMW(a)stentor.ca; WarrenGA(a)stentor.ca; PackmanJ(a)stentor.ca; ReilleyJA(a)stentor.ca; RochfordM(a)stentor.ca; GirardLP(a)stentor.ca; BirdBR(a)stentor.ca; WarrenL(a)stentor.ca Subject: Concert Network Scheduled Maintenance - UK (Subnet 4) Ms. Regan; On Saturday, February 6th as well as Sunday, February 7th, there will be maintenance performed in the UK (Subnet 4) to upgrade the Firmware on the trunk cards. The maintenance is a prerequisite for the 8.5 upgrade that is scheduled for February 12th . A separate notification will be sent outlining the specific details of the 8.5 upgrade as well as the corresponding impact statement . This notification is to advise you that the service impact ,relating to the trunk maintenance, will result in pvc's rerouting on both nights between 01:00 and 06:00 GMT. Any unexpected outages can be reported to 1-888-977-6678. Regards, Linda J. Brown CCSC - Concert Canada Service Center Concert Change Management 613-781-9382

1 0

Re: Incompetance abounds at the InterNIC
by Dean Anderson 22 Jan '99

22 Jan '99

Once again, we have a tempest in a teapot. And once again this "tempest" is just a means of obscuring the real problem. Speculators aren't the problem. They are just a scapegoat. I'm probably going about this the wrong way by arguing the details of speculation, instead of getting people to focus on the real problems of performance and management. But Internic isn't very forthcoming in how they manage their systems. Even so, I think I could run an automated database service for very little cost per transaction. On the order of hundreths of a cent per transaction. Charging $35 means means that one can make many, many thousands of non-revenue transactions per revenue generating transaction. So I'll make the claim that if Internic can't do it for a comparable cost, that isn't justification for restrictions on the user community. You all remember when Internic was formed, and registrations were going to cost money, that many people thought $50.00 a year was outrageously high, right? At 01:55 PM 1/20/1999 -0700, Pete Kruckenberg wrote: >There is a key difference, and that is that stock speculators pay for the >right to speculate, so the system can afford to scale to meet the >increased volume. Actually, quite a few stock speculators don't pay for the privilege. Many speculators are stock brokers or floor traders who speculate cost free (other than the cost of the stocks they buy). And you should note that now that the stock exchanges are now nearly fully automated (though much less so than Internic), discount brokerages now charge less than Internic. Trading never stops now. Again, I think a first class, high availability, high security database service can be operated without significant per transaction costs. Indeed, it is a damning indictment of Internic that stock brokerages charge less, yet provide more secure, and more highly available computer services. You also assume that domain speculators are the only ones who register more domains than they pay for. They aren't. I'll bet many here have registered domains that they later didn't want and didn't pay for. Further, speculators ultimately pay for the domains they sell. What you are really complaining about is that they register some domains they don't pay for. The only reason you are complaining about that is because someone pinned the blame for Internic problems on speculators. The claim that "speculators don't pay" doesn't stand up. Neither does the claim that speculators cause Internic problems. They don't. I think Internic can afford to scale with the volume regardless of speculation. Internic is a nearly fully automated process which charges 35.00 for a completed registration. I am going to go out on a limb that a single database transaction costs very nearly nothing. So without doing the math for a single registration, I think Internic *afford* a large number of non-completed transactions for each completed transaction. Speculators that actively try to sell their domains quite likely cause more domains to be registered, and so they increase the Internic sales revenue. I haven't seen any evidence that the costs of their non-completed transactions are more than cost of their completed transactions. It costs them much more to fill out the registration template and scan the news than it does for Internic to (automatically) process the registration. If they don't sell more than their time is worth, they won't be able to afford to keep doing it. So it doesn't make any sense that they register to many hundreds of thousands of domains per successful registration. And if they generate a net-gain for Internic, thats a good thing. The only speculators that might be able to register thousands of domains with little effort are the ones who register on-hold domains. But they are doing a favor for Internic, because they are collecting fees. More importantly, they will ultimately encourage people to make their payments on time. Thats a good thing for Internic. Quite possibly, Internic can improve its efficiency with regard to domain expirations and re-registrations. But that doesn't mean that one should go though contortions to stop speculators. I certainly don't want to give up the current system that allows one to register domains with delayed or canceled payment and immediate duplicate notification. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5 4

The Cidr Report
by Tony Bates 22 Jan '99

22 Jan '99

This is an auto-generated mail on Fri Jan 22 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 22Jan99 0) General Status Table History ------------- Date Prefixes 150199 55155 160199 55240 170199 55247 180199 55241 190199 55868 200199 55938 210199 55534 220199 55393 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4442 Number of ASes announcing only one prefix: 2186 (1168 cidr, 1018 classful) Largest number of cidr routes: 355 announced by AS3561 Largest number of classful routes: 1012 announced by AS701 1) Gains by aggregating at the origin AS level --- 22Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 387 143 244 63.0% UNKNOWN AS701 1012 859 153 15.1% UNKNOWN AS2493 319 173 146 45.8% UNKNOWN AS174 655 541 114 17.4% UNKNOWN AS11305 115 7 108 93.9% UNKNOWN AS4200 189 97 92 48.7% UNKNOWN AS3749 158 66 92 58.2% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4755 147 72 75 51.0% UNKNOWN AS4293 208 137 71 34.1% UNKNOWN AS549 218 152 66 30.3% UNKNOWN AS4740 387 325 62 16.0% UNKNOWN AS1221 399 339 60 15.0% UNKNOWN AS7046 253 196 57 22.5% UNKNOWN AS1239 540 486 54 10.0% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS7657 140 89 51 36.4% UNKNOWN AS7545 110 59 51 46.4% UNKNOWN AS577 221 172 49 22.2% UNKNOWN AS10928 98 49 49 50.0% UNKNOWN AS7496 76 28 48 63.2% UNKNOWN AS852 177 134 43 24.3% UNKNOWN AS719 452 409 43 9.5% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 72 36 36 50.0% UNKNOWN AS6897 64 28 36 56.2% UNKNOWN AS3561 723 687 36 5.0% UNKNOWN AS7122 110 76 34 30.9% UNKNOWN AS2764 324 291 33 10.2% UNKNOWN AS6332 101 70 31 30.7% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Who uses RADB/IRR?
by Gerald Andrew Winters 22 Jan '99

22 Jan '99

Dan, Heh-heh. Most people want me to register a maintainer ... ;) The problem with your request is there is no standard method of making routing table globally accessable. The best I can do for you is to give you a pointer to our IPMA pages which has lots of excellent infomation, including our route server routing tables at all of the exchanged points. So you can see the routing tables of those who peer with our route servers. Go to www.merit.edu and click on 'Research projects', 'Internet Performance, Measurement & Analysis (IPMA)', 'Statistics and Daily Reports', and 'Internet Routing Table'. >From there you can navigate the various exchange points you are interested in. good luck. --jerry From: Daniel Senie <dts(a)senie.com> To: nanog(a)merit.edu Date: Thu, 21 Jan 1999 23:39:47 -0500 Subject: Who uses RADB/IRR? Sender: owner-nanog(a)merit.edu Message-ID: <36A80113.53178B82(a)senie.com> Organization: Amaranth Networks, Inc. X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Status: RO I'd like to find out which networks use the RADB or IRR databases to build their routing policies, and how to look at their current databases or access looking glass or equivalent systems. It's becoming difficult to take a network multihomed without having parts of the net appear to be black holed in other parts of the world. It appears difficult to ascertain which networks are doing what with policies. So far I am aware of CW.NET and ANS.NET using the routing databases to build their policies, but am not aware of a way to look at their tables. If anyone has pointers to their resources, or those of other nets using the routing registries, please let me know. -- ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com

1 0

Change in InterNIC Tracking Numbers (fwd)
by Patrick Greenwell 22 Jan '99

22 Jan '99

Fyi.... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com (tinc) \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ---------- Forwarded message ---------- Date: Fri, 22 Jan 1999 09:52:50 -0500 From: Chuck Gomes <cgomes(a)internic.net> Reply-To: cgomes(a)NETSOL.COM To: DOMAIN-POLICY(a)LISTS.INTERNIC.NET Subject: Change in InterNIC Tracking Numbers Effective Thursday, January 21, 1999, tracking numbers have a new look. To be able to accommodate the large numbers of requests being received, we had to change the sequential number (to the right of the decimal point) to a hexadecimal number. Tracking numbers will look like this: NIC980121.1a3e9. There will still be 5 characters to the right of the decimal point but there will 16 possible digits instead of 10: 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f. [a=10, b=11, c=12, d=13, e=14 and f=15]. A tracking number such as NIC980121.58123 would no longer mean that it was request number fifty eight thousand one hundred twenty three. The number would actually be 5x(16x16x16x16)+8x(16x16x16)+1x(16x16)+2x16+3 which would be equal to 360,739 as a decimal number. NOTE: tracking numbers assigned prior to January 21st will be in the old (decimal) format. Tracking numbers assigned on January 21st and forward will be in the new (hexadecimal) format. The date portion of the number will not change. Chuck Gomes Vice President, Customer Programs Network Solutions, Inc. -- DOMAIN-POLICY administrivia should be sent to <listserv(a)lists.internic.net> To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP"

1 0

Incompetance abounds at the InterNIC
by John Fraizer 22 Jan '99

22 Jan '99

Now, isn't this special? ----- Transcript of session follows ----- ... while talking to rs.internic.net.: >>> DATA <<< 451 qq write error or disk full (#4.3.0) <hostmaster(a)internic.net>... Deferred: 451 qq write error or disk full (#4.3.0) Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old Just what does our $35/yr per domain go towards? I would venture to guess that drive space costs a whole shit load less that all the damned InterNIC commercials I've been seeing on T.V.! Does anyone know just who we need to bitch very loudly to? ------------------------------------------------------------------ ML.ORG is gone. Check out http://www.EZ-IP.Net - It's *FREE* ------------------------------------------------------------------ Get your *FREE* Parked Domain account at http://www.EZ-Hosting.Com ------------------------------------------------------------------ John Fraizer | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation PGP Key fingerprint = 7DB6 1CA2 DAA6 43DA 3AAF 44CD 258C 3D7E B425 81A8

9 15

Who uses RADB/IRR?
by Daniel Senie 22 Jan '99

22 Jan '99

I'd like to find out which networks use the RADB or IRR databases to build their routing policies, and how to look at their current databases or access looking glass or equivalent systems. It's becoming difficult to take a network multihomed without having parts of the net appear to be black holed in other parts of the world. It appears difficult to ascertain which networks are doing what with policies. So far I am aware of CW.NET and ANS.NET using the routing databases to build their policies, but am not aware of a way to look at their tables. If anyone has pointers to their resources, or those of other nets using the routing registries, please let me know. -- ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com

1 0

Re: Incompetance abounds at the InterNIC
by Adam D. McKenna 21 Jan '99

21 Jan '99

From: Phil Howard <phil(a)whistler.intur.net> :"Some" communication? : :It's not an issue of "completely" fill ... it's an issue of logistics. : :This "communication" you speak of will involve probably thousands of :companies when you consider the whole range of all of them that interconnect :(even though they don't interroute). Any one of them that already has an :established addressing _MAY_ end up connecting to any other of them that :already has established addressing. That means this "communication" has :to basically implement an entire allocation structure. And every business :that is not even yet connected would have to be sure their use of RFC1918 :space conforms to this allocation structure. You don't sound very sure of your arguments. To which thousand companies are you referring? :Basically, it's like saying, RFC1918 space will no longer be private :address space that can be used on a whim, but instead will now be allocated :by yet another entity. Usage of RFC1918 space shouldn't be determined by "whims", it should be planned just like anything else at a company is planned, and it should be accounted for. :> The best way to do this is with a firewall (companies doing this probably :> already have one, otherwise their "private" network ain't so private), and :> just about every firewall worth putting on a box will do NAT. You map :> individual machines that need their own IP address directly through on a :> one-to-one relationship, and the rest you let the firewall masquerade :> through. Conserves "real" IP space. : :NAT wasn't a common reliable tool when these things were established. The :first of these I remember getting involved in over 4 years ago. It is a :little better today, but the good ones are very costly. You will fail to :convince the vast majority of these companies to buy an overpriced super :firewall that does highly scalable NAT reliably when their needs are met :with a low priced router (e.g. Ascend Pipeline 50 to Cisco 25XX scale). There was a discussion of low-priced high-capacity NAT solutions a few months ago on NANOG, I'm sure if you look in the archives you will find it. :Yes, if you were starting this kind of thing today, NAT would probably be :the better way to go. But as well all know, business does not just go around :spending money to revamp what is currently working fine. That's fine. As long as they don't mind spending time and money renumbering their entire network once it gets connected to the internet. :And further, that also makes 10/8 unavailable for actual internal uses for :which RFC1918 was intended. And since many such companies already do have :RFC1918 in use for the intended purposes, this isn't the space that can be :just simply moved in to. RFC1918 is entitled "Address allocation for private internets". I think it describes exactly what you are talking about. :Dream on. : :You have to include _EVERY_ company that might ever do this. Not really. Companies do not usually route their entire corporate network to each other. When one company wants to connect to another, all they need to do is come up with one or two common subnets that neither company is using at that particular time, and only route between those IP's. That way, it doesn't matter to company A what company G which is two "corporate hops" away is doing. --Adam

6 6

RE: RE: ATM Switch Interoperability
by Martin, Christian 20 Jan '99

20 Jan '99

Steve, In your experience, then, would you agree that higher SCR rates should have higher MBSs, so that the Burst Tolerance linearly increases with SCR? I have a problem with an MBS of 100 for SCR 1000 up to 1000000. CDVT gives us some bucket depth, but I don't think we're clumping. The LS1010 doesn't shape VBRnrt, just polices. At the far end is a Fore ASX1000. So, we have three different vendors in the mix. Our ATM provider sets MBS to 100 no matter the contract. This seems too restrictive. Chris > > Here is the function for the relationship of Burst Tolerance > BT (time) and Maximum Burst Size MBS > (a number of cells). Most switches allow you to set the MBS > and then they calculate the BT based > on this function. Definitions: Ts = 1/SCR, Tr = 1/PCR, ts = BT > > MBS = | 1 + ((CDVT + ts) / (Ts - Tr)) | where |x| > stands for the largest integer less than x. > for Tr > 1 and CDVT > Tr -1. > > > This function is based on using a unit of micro-seconds for > each variable. The corresponding function is used > to calculate the maximum burst size B (a number of cells) on > the PCR policing: > > B = | 1 + ((CDVT) / (Tr - 1)) | For Tr > 1 where > |x| stands for the largest integer less > than x. CDVT must be greater than Tr - 1. > > This function is also based on units of micro-seconds. It > breaks down if Tr < 1 microsecond. At that point a smaller > unit of time would need to be subtracted from Tr instead of 1 > microsecond. This only matters with very large PVCs > with a PCR of over 1000000 cells per second. > > These values for MBS and CDVT are usually defaulted for the > user and the same default applies no matter what > the SCR and PCR values are. Some ATM providers set the CDVT > and MBS very low and adjust up if problems like > you are observing appear. > > If the lightstream does traffic shape properly this should > not be an issue. If you do have traffic shaping on the lighstream > you could set the PCR=SCR. You will lose a small amount of > burst but will be able to sustain at SCR. The bursts do not > really buy you a large amount of extra traffic anyway (unless > CDVT and MBS are set high) they are really just there to > allow for variations in accuracy of policing between devices. > > Steve Murray > MCI Worldcom > steve.murray(a)wcom.com > > > >>> "Martin, Christian" <CMartin(a)mercury.balink.com> 01/15 9:19 PM >>> > >We have it matched to the policing policy of the Network > Provider. By > >increasing the CDVT, we gain some bucket depth, but we are > only MUXing 5 > >VCCs over one VP. There shouldn't be too much clumping, espescially > >considering the load on the switches(low). One thing is interesting, > >though: The far end (customers) are all running over DS3 using HEC > >delineation. > > > >A curiosity: Given the parameters below for the contract, > particularly > >the MBS and CDVT, does it appear that we are being cheated? From my > >understanding of the UNI 3.1 spec, the MBS should be adjustable > >according to SCR/PCR, given the fact that CDVT is defined as the same > >for both SCR and PCR buckets. > > > >One obstacle that myself and my colleagues have not been able to > >overcome is the use (aside from bucket calculation) of the Burst > >Tolerance. It is obviously proportional to the MBS, but again, it > >appears as if a contract specifying a PCR/SCR of > 100000/50000 cells per > >sec, should have a higher MBS than a 10000/5000 cell/sec contract. > > > >Any insights? > > > >Chris > > > > - > >

1 0