April 1996 - Test - lists.nanog.org

Re: NANOG/IEPG/ISOC's current role
by Hank Nussbacher 03 Apr '96

03 Apr '96

I use a simple rule that seems to work somewhat in regards to renumbering. I control the Israeli /16s blocks - i.e. 192.114-118.0.0/16. An organization that uses a /22 or more (and use means more than 50% of the IP address space is being used), is allowed to move around with it from ISP to ISP (i.e. portable). If you have 500 machines - it is painful to renumber (not impossible). If you have 30 machines and a /24, then renumber - and I have reclaimed dozens of /24s in this fashion. Hank

1 0

Re: Sprint's agenda
by avg＠postman.ncube.com 03 Apr '96

03 Apr '96

Jon Zeeff wrote: >> And the global routing table grows. >We asked Sprint for an exception to their routing policy in a case that >would clearly reduce routing table size. They said no. Everyone is >free to draw their own conclusions regarding Sprint's policies and the >real motivations behind them. Cisco's configurations aren't rubber. You can only stretch them so far. Every exception is more stuff in configuration on a dozen of routers. This also increases CPU load. If you think Sprint's goal is to reduce table size you're wrong. The goal is to avoid routers going belly up from overload. So the approach is to have a blanket policy which is not too expensive to compute but does contain growth _on average_. --vadim PS. Here's line counts for you to appreciate better why Sprint engineering does not like exceptions: 1291 icm-dc-1-confg 191 icm-dc-2-confg 542 icm-dc-2b-confg 1155 icm-dc-3-confg 792 icm-fix-e-confg 842 icm-fix-w-confg 314 icm-lac-1-confg 1194 icm-mae-e-confg 164 icm-moscow-1-confg 398 icm-pen-1-confg 447 icm-pen-2-confg 418 icm-stockholm-2-confg 190 icm-uk-1-confg 399 sl-ana-1-confg 386 sl-ana-2-confg 737 sl-ana-3-confg 559 sl-ana-4-confg 435 sl-ana-5-confg 451 sl-ana-6-confg 242 sl-ana-7-confg 356 sl-atl-1-confg 361 sl-atl-2-confg 496 sl-atl-3-confg 420 sl-atl-4-confg 353 sl-atl-5-confg 401 sl-che-1-confg 403 sl-che-2-confg 417 sl-che-3-confg 301 sl-chi-1-confg 521 sl-chi-10-confg 587 sl-chi-11-confg 187 sl-chi-12-confg 513 sl-chi-13-confg 480 sl-chi-14-confg 393 sl-chi-15-confg 354 sl-chi-2-confg 440 sl-chi-3-confg 713 sl-chi-4-confg 608 sl-chi-5-confg 453 sl-chi-6-confg 610 sl-chi-7-confg 453 sl-chi-8-confg 507 sl-chi-9-confg 572 sl-chi-nap-confg 496 sl-dc-1-confg 734 sl-dc-10-confg 677 sl-dc-11-confg 642 sl-dc-12-confg 575 sl-dc-13-confg 543 sl-dc-14-confg 459 sl-dc-15-confg 503 sl-dc-16-confg 791 sl-dc-17-confg 382 sl-dc-18-confg 391 sl-dc-2-confg 495 sl-dc-3-confg 731 sl-dc-4-confg 551 sl-dc-5-confg 847 sl-dc-6-confg 406 sl-dc-7-confg 662 sl-dc-8-confg 677 sl-dc-9-confg 181 sl-dc-s-1-confg 495 sl-fw-1-confg 502 sl-fw-10-confg 532 sl-fw-11-confg 518 sl-fw-12-confg 512 sl-fw-13-confg 472 sl-fw-14-confg 359 sl-fw-15-confg 484 sl-fw-2-confg 831 sl-fw-3-confg 480 sl-fw-4-confg 479 sl-fw-5-confg 413 sl-fw-6-confg 460 sl-fw-7-confg 507 sl-fw-8-confg 449 sl-fw-9-confg 391 sl-hrn-1-confg 369 sl-kc-1-confg 368 sl-kc-2-confg 1076 sl-mae-e-confg 739 sl-mae-w-confg 673 sl-pen-1-confg 447 sl-pen-10-confg 390 sl-pen-12-confg 512 sl-pen-13-confg 316 sl-pen-14-confg 352 sl-pen-15-confg 948 sl-pen-2-confg 613 sl-pen-3-confg 451 sl-pen-4-confg 524 sl-pen-5-confg 606 sl-pen-6-confg 546 sl-pen-7-confg 542 sl-pen-8-confg 505 sl-pen-9-confg 389 sl-sea-1-confg 392 sl-sea-2-confg 442 sl-sea-3-confg 438 sl-sea-4-confg 375 sl-sea-5-confg 459 sl-stk-1-confg 600 sl-stk-10-confg 590 sl-stk-11-confg 492 sl-stk-12-confg 504 sl-stk-13-confg 358 sl-stk-14-confg 380 sl-stk-15-confg 544 sl-stk-2-confg 531 sl-stk-3-confg 904 sl-stk-4-confg 618 sl-stk-5-confg 638 sl-stk-6-confg 555 sl-stk-7-confg 592 sl-stk-8-confg 541 sl-stk-9-confg 461 sl-stk-nap-confg 61453 total

1 0

RE: NANOG
by avg＠postman.ncube.com 03 Apr '96

03 Apr '96

Bob Metcalfe wrote: >Perhaps I am confusing terms here. How can it be a fact that >"store-and-forward delays are a mere fraction of wire propagation delays?" >I don't think so. Check me on this: >Packets travel over wires at large fractions of the speed of light, but >then sadly at each hop they must be received, checked, routed, and then >queued for forwarding. Do I have that right? Not "checked". Nobody computes checksums in gateways for transit packets. Updating hopcount doesn't require recalculation of IP checksum, it can be done incrementally (there was an RFC to that effect, don't remember which). >Forget checking, routing, and queueing (ha!), and you get, I think, that >store and forward delay is roughly proportional to the number of hops times >packet length divided by circuit speed (N*P/C). Wrong. This is oversimplification, as slow tail-links consume bulk of time. This is very comparable to going 90% of the way at 100mph and 10% at 10mph -- what is the average speed? Right, that's 52.6 mph. Note that 10% of the way slows down everything by a half. >But at 30 hops of thousand byte packets at T1 speeds, that's, what? 4,000 >miles of prop delay. A mere fraction? You won't find 30 hops at T-1 in the real life no matter how hard you try. It's more like Ethernet-T1-FDDI-T3-FDDI-T3-T3-FDDI-T3-FDDI-T1-Ethernet- T0-Ethernet. And, BTW, the average size of packet on Internet is 200 bytes. Store-and-forward of 200-byte packet is 60 microseconds with T-3 wire which is about 5 miles at light speed. Moreover, large packets occur in bulk transfers, where sliding windows are efficient -- to the effect that you see the delay only once, when you do initial TCP handshake. >But of course, getting back to 1996, N*P/C doesn't count checking, routing, >and queueing -- queueing gets to be a major multiple with loading. Queueing Theory 101 is recommended. If incoming traffic in G/D/1 system is less than capacity the average queue size is less than 1. If load is more than capacity the average queue size is infinity. I.e. the delay in network in case of congestion depends on size of buffers along the path, and not number of hops, period. The "best" size of buffers is choosen to accomodate transient congestions, i.e. determined from bandwidth*delay product ("delay" here is RTT). I.e. in properly tuned network the congestion delay is about 2 times "ideal" RTT plus something to accomodate topological irregularities. RED (by VJ and co.) allows to reduce size of congestion buffers by about 1/2 because it actively anticipates congestions instead of acting when they already happened as tail-drop does. And, BTW, with IP you can skip the "store" part, too; you only need to look at IP header to make a routing decision. The rest you can simply channel thru. >Oh, I forgot retransmission delays too, at each hop. What's that? IP does not do any retransmissions between gateways. >And I forgot the increasing >complications of route propagation as hops increase... He-he. That is far from being as simple as you think. Topology means a lot more than the diameter for complexity of routing computations. >If I am, as you say, the first person to be concerned with the growth of >Internet diameter, which I doubt, then I deserve a medal. Or is my >arithmetic wrong? Ease my cluelessness. You seem to offer opinions with little or no checking of background facts. I bet you're a victim of Flame Delay crowd propaganda. I certainly heard that line of reasoning from them, got a good laugh, too. As for cluelessness -- i already noted that diameter grows as a logarithm of network size, while bandwidth grows at least as linear to the size. That means that the fraction of "store-and-forward" penalty in the end-to-end delays is diminishing as network grows. So not only you're worrying about insignificant thing, you appear concerned with something which actually improves with scale! --vadim

1 0

Re: NANOG/IEPG/ISOC's current role
by Paul Ferguson 02 Apr '96

02 Apr '96

At 07:30 PM 4/2/96 -0800, Michael Dillon wrote: >> >Hmmm.... ISP has T1 to SPRINT, wants to switch to MCI, SPRINT says, OK >> >you have a choice, either renumber or pay us to route your traffic to MCI >> >via a private exchange point so we don't have to knock holes in our >> >aggregate. That way you can use SPRINT's addresses and MCI's T1, but for >> >a fee. >> >> And the global routing table grows. > >If this is done with a private two-party exchange point, then can't it >also be done without any change in the global routing table? > I'm not sure this is practical. In any event, this why people have been bitching about people punching holes in large CIDR blocks. - paul

1 0

Re: NANOG/IEPG/ISOC's current role
by Sean Donelan 02 Apr '96

02 Apr '96

What is NANOG's role? I was surprised to read in the March 25 issue of NetworkWorld Alecia Cooper at Sprint comments that Sprint is just following NANOG's recommendations to block addresses to minimize the number of router table entries. I must have missed something, because I don't remember NANOG ever making any recommendation, of any sort. Is this just a case of bad reporting by Joanie Wexler at NetworkWorld? A bad case of passing the buck by Alecia Cooper at Sprint? Or something else? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

7 8

Re: vocalizing majors, etc, etc.....
by Paul Ferguson 02 Apr '96

02 Apr '96

"No one expects the Spanish Inquisition!" :-) - paul At 08:11 PM 4/2/96 -0500, Mike O'Dell wrote: > >"Do you now, or have you ever attended meetings of the Global > Routing Conspiracy?" >

1 0

RE: NANOG
by sob＠academ.com 02 Apr '96

02 Apr '96

Bob writes: > Jerry, Jerry, Jerry, the problem is not that the Internet's chief 100 > engineers, whoever they are, fail to report their problems to me, it's that > they (you?) fail to report them to anybody, including to each other, which > is half our problem. Actually, there has been some work done on this. There was a NSFNET Trouble Ticket standard developed by the RAC. The report is available as a pdf file from this URL: ftp://ftp.academ.com/pub/misc/troublet.pdf. Unfortunately, shortly after this work was done, the NSFNET ceased to exist. > So, you say, increasing Internet diameters (hops) are only of concern to > whiners like me? There are no whiners LIKE me. I am THE whiner. And hops > ARE a first class problem, Jerry, or are you clueless about how > store-and-forward packet switching actually really works? I'd like to encourage you to discuss this issue specifically. I am writing an Internet-Draft on end-system management issues in the face of the explosive growth of the Internet and this is one of the ones I am writing about. Your views would be most welcome in developing this document. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: NANOG/IEPG/ISOC's current role
by salo＠msc.edu 02 Apr '96

02 Apr '96

> To: Sean Donelan <SEAN(a)sdg.dra.com> > Cc: nanog(a)merit.edu > Date: Tue, 02 Apr 1996 12:38:29 -0500 > From: Curtis Villamizar <curtis(a)ans.net> > [...] > NANOG is a place where operational issues are discussed. They are not > voted apon and so there is not official decrees from NANOG. I am no > more a spokesperson for NANOG than for Sprint. Here's my opinion if > you want it. > [...] Nice summary. -tjs

2 1

Re: NANOG/IEPG/ISOC's current role
by sob＠academ.com 02 Apr '96

02 Apr '96

Tim writes: > It is not a strong leap of the imagination to believe that NANOG, > the vocal majority, supports selective route-filtering to control > routing table growth and was very aggressive to oppress the > those whom dared to stand alone and challenge there will. > > Please keep in mind that as in *any* group, NANOG included, by > virture of allowing a few dominate voices to represent the > group, does bear responsibility for the perception others > view the group. You say the "vocal majority" in the first paragraph and then the "few dominate voices" in the second paragraph. Which is it? If you had said a "vocal minority" in the first paragraph, it would make your comments much more consistent. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

2 1

RE: NANOG
by David C. Kovar 02 Apr '96

02 Apr '96

We have a business plan in place for doing exactly this, and a lot more. It's pretty simple to do, with the right setup. We have no intention of sellings ads on the page, though. -David >This is a good point. If there were a list somewhere which collated all >of the trouble reports from all of the ISP's then some entrepreneur could >set up an Internet traffic report WWW site and make all the mass of >trouble reports palatable for end users, including stories about ladies >in Lincolns. > >This entrepreneur could get rich selling ads on their WWW site and >everyone would know what is going on. > >> Now, NANOG -- not affiliated with anybody, you say, not even the Internet >> Society. OK, I stand corrected. So, if not ISOC, who are IEPG and NANOG? >> Do IEPG and NANOG have anything to do with one another? By the way, is >> IETF not ISOC too? See www.isoc.org. > >Even though I know how all this came about and how groups like NANOG >operate (what group!) I still don't believe it when people say that NANOG >doesn't set policy and NANOG is not affiliated with anybody. The fact is >that NANOG appears to set policy and NANOG appears to be affiliated with >somebody and that appearance is what counts until NANOG pipes up and >states what their official policy and official affiliations are. > >> Settlements, "wrong on the face?" Or are you just too busy busy busy >> defensive to argue? > >Settlements are contrary to NANOG policy. It is also contrary to NANOG >policy to engage in long drawn out debates about things which have >already been decided, like "settlements are wrong". The policy is >unwritten and to a certain extent, non-verbal, but it is policy nevertheless. > >> So, you say, increasing Internet diameters (hops) are only of concern to >> whiners like me? There are no whiners LIKE me. I am THE whiner. And hops >> ARE a first class problem, Jerry, or are you clueless about how >> store-and-forward packet switching actually really works? > >I have had to explain to ISP's how to do email relaying so that their >customers can get email back and forth from fringe locations. It's >usually an asymmetrical problem so it shows up when a person can receive >email but cannot send a reply. > >BTW, the trick is to address it like this joe%farawayplace.com(a)majorhub.com > > >Michael Dillon Voice: +1-604-546-8022 >Memra Software Inc. Fax: +1-604-546-3049 >http://www.memra.com E-mail: michael(a)memra.com > > >

1 0