- Test - lists.nanog.org

Re: New Internet Routing Statistics
by Sean Doran 03 Apr '96

03 Apr '96

| So sprint will coperate at least to the extent that MCI, ANS, and UUNET | are already doing so? If Craig had previously pointed out that he would like to have gotten routes from us that would not be propagated unless specifically requested by us, then I don't think it would have been too difficult to have done the two line adjustment to our already-existing peerings with the two RSes at MAE-EAST in order for us to have shown up on the hallowed list in his message today. Of course, that would have also deprived you of a front-page Cook Report scandal, and several messages here on the NANOG list. So, think of this as job creation at work, maybe. | I'd think that is good news. Do you have any kind of time line, Sean? | June 1? July 1? Well, I went digging, and couldn't find any relevant email on the first pass. Perhaps such a message will find its way to the appropriate people (maybe for the second time, if we lost things on this end), so we know what routing information is wanted and where and when, and what exactly it will be used for. I see no difficulty with announcing routes to the RA specifically for gathering the sorts of statistics they have been thinking about. Indeed, I believe that I have made this clear in public places a number of times in the past. We now return you to the regularly scheduled making of mountains out of mole-hills. Sean. P.S.: SL-MAE-E uptime is 1 week, 4 days, 12 hours, 37 minutes System restarted by power-on at 10:28:06 EST Fri Mar 22 1996 BGP neighbor is 192.41.177.166, remote AS 2885, external link NEXT_HOP is always this router BGP version 4, remote router ID 192.41.177.166 BGP state = Established, table version = 2186252, up for 1w0d Last read 0:00:57, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 30 seconds Received 16570 messages, 0 notifications, 0 in queue Sent 16605 messages, 0 notifications, 0 in queue Incoming update network filter list is 112 Outgoing update network filter list is 95 Outgoing update AS path filter list is 35 Route map for incoming advertisements is RA Connections established 4; dropped 3 [moreover, we set the peering up more than a year ago]

2 1

Re: Sprint's agenda
by Sean Doran 03 Apr '96

03 Apr '96

There is nothing new here; it is Common Knowledge that Sprint is the source of all evil on the Internet, and is out to crush small providers, and make sure that everyone in the world burns his or her toast, and so on and so forth. Everyone has been welcome to draw their own conclusions from day one. Sean. - -- | From nanog-owner(a)merit.edu Wed Apr 3 15:52:13 1996 | From: jon(a)branch.com (Jon Zeeff) | Subject: Sprint's agenda | To: pferguso(a)cisco.com (Paul Ferguson) | Cc: michael(a)memra.com, nanog(a)merit.edu | MIME-Version: 1.0 | Content-Transfer-Encoding: 7bit | Sender: owner-nanog(a)merit.edu | | | > 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. | |

1 0

RE: NANOG/IEPG/ISOC's current role
by Jim Fleming 03 Apr '96

03 Apr '96

On Monday, April 01, 1996 4:10 PM, Michael Dillon[SMTP:michael@memra.com] wrote: @On Mon, 1 Apr 1996, Sean Donelan wrote: @ @> 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? @ @It's most definitely something else. Most people are trained from birth @that organizations with acronyms rule the world, thus NANOG and IEPG @and ISOC must be the rulers of the Internet world. @ Yes, as more people from various walks of life get involved in the Internet, there is going to be confusion because these "new" people are going to assume that there is something behind these fancy acronyms... when they find out that the Internet is like a large "movie set" they may get very upset...or at least disoriented...they will find that the net is not an Information Superhighway but rather a parking lot with carnival rides... ...this will probably send many people BACK to their families, churches, schools, governments, corner barber shops and neighbors to try to find something "real" in their life...in this respect, the Internet may cause people in local areas to become "better connected" because much of the net is very socially disconnected... ...virtual is fun but when the rubber hits the road...people buy ($$$) real... @Since most NANOG/IEPG/ISOC people are clueless when it comes to things @like public relations, press releases, spin control, etc... is it any @wonder that the press marches merrily off in their own direction. @ I am not sure they are clueless, they may have just chosen to live in a different world where the traditional press has little meaning....keep in mind that Dolphins do not get involved much in the world of Cats and Dogs... @There is actually opportunity here for groups like NANOG to have some @influence and communicate with the public in a positive fashion. I @suggest that a good first step would be to release a communique to the @press after every NANOG meeting and a good second step would be to urge @ISOC to spend more money on general educational issues to make people in @general more aware of operational and architectural issues. @ @ @Michael Dillon Voice: +1-604-546-8022 Maybe people that live largely in the Internet (and other places) are going to discover what the other 99% of the people on planet earth already know.... In order to get people working in a common direction you have to have some common purpose, some common goals and a reason and benefit for an individual to be associatted with an entity. Having a short, catchy acronym is not enough. Most humans do not join clubs or help promote a cause simply because it exists. One or more of the basic human motivators need to be in place. (education, money, power, entertainment, self-fullfillment, social status, peer acceptance, pleasure, etc.) The Internet is currently going through a transition...many of the traditional groups that have been formed in the "real world" (whatever that is) are moving some or part of their member communication to the Internet. Most of it shows up in the World Wide Web...little by little, traditional groups will discover some of the other "services" available on the net. When this occurs these groups will likely overshadow the tiny groups that helped to build the net. I suggest that "net people" give up on the idea of building more and more "movie sets" and instead, join with the real people and help facilitate their increased involvement with the net. This involvement is inevitable and as they say..."If you can't beat them... join them"...By joining with existing groups, netizens can have a significant impact on how those groups merge into the increasing traffic on the Information Parking Lot... -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

1 0

Re: vocalizing majors, etc, etc.....
by bill＠sf.net 03 Apr '96

03 Apr '96

>"Do you now, or have you ever attended meetings of the Global > Routing Conspiracy?" > >"Huh?? I went to a NANOG meeting a few times to see what went on there." > >"So you ADMIT that you have attended SEVERAL meetings of the > Global Routing Conspiracy?" [deletia] Mike, Is this based on personal experience? Or is this merely a nightmare you anticipate? ;) Bill

1 0

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 03 Apr '96

03 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 03 Apr '96

03 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 03 Apr '96

03 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