- Test - lists.nanog.org

Not to beat a dead horse
by Avi Freedman 22 Dec '95

22 Dec '95

But I still see 4 /24s advertised in 208/8: 208.0.1.0 208.0.4.0 208.0.5.0 208.0.9.0 Now, besides the fact that 208.0.4.0 & 208.0.5.0 could be 208.0.4.0/23 (grin), what IS the appropriate way to deal with an ongoing situation where un-NIC-allocated IP space is advertised on the Internet? We have no plans to implement incoming route filters on 208/8 - who knows when the NIC will start allocating out of it. Obviously, having announcements of unallocated address space "work" for the long term is a bad precedent to set. Yes, it can be a pain to deal with the NIC (which is following policies approved of by most NSPs) to get address space, but ... Avi

2 1

Are the Route Servers Viable Solutions That Are Being Held Hostage?
by Gordon Cook 22 Dec '95

22 Dec '95

I am confused - hope I am not the only one. A well respected member of the IETF wrote privately to me: Gordon, what do you think the RR is for? it is a database - why would it have any impact on *if* and under what conditions provider A would want to talk to provider B at a NAP? the NAP rules are *specifically* that peer-to-peer agreements are required, that is one of the reasons the NAPs are level 2 system ----------------------------------- OK - fair enough - I turned next to the routing arbiter web pages listed by bill manning. There I found the following under advantages of using the route servers of the routing arbiter: Quote: Scalable Routing As noted earlier, an ISP's routers on a NAP would need to establish full-mesh BGP peer sessions among themselves in order to exchange routing information without the presence of the RS. That is, if there were N ISPs present at a NAP, each would have N-1 peering sessions. When N is a large number, a sizable load could be placed on each router in order to maintain the required peering sessions and process the needed routing information. With the RS, each ISP only needs to peer with one RS--or two for backup purposes--instead of maintaining N-1 peer sessions. Separation of Routing and Forwarding If a NAP did not have a Route Server, each ISP router would need to perform two major functions at all times: routing processing and packet forwarding. A heavy traffic load could put a substantial extra burden on the routers, which would also need to process routing information. The load would be particularly heavy if the number of peering sessions was not small, the number of destination routes was large, and the policy was complicated. It would be ideal to have the routers concentrate on forwarding packets, and have another system handle routing. The Route Server achieves just this goal: it processes routing information for each ISP's router, thus enabling the ISP routers to concentrate on packet switching. Simplify Routing Configuration Management on ISP's Routers The Route Server processes routing information based on the routing policy defined by each ISP. This includes route filtering, e.g., setting up routing firewalls, selecting the desired path towards all destinations the ISP will be reaching, and other tasks that would normally be configured and implemented on the ISP routers. The RS thus greatly reduces the routing processing, filtering and configuration management load on the ISP routers at the NAPs. Note that RS can facilitate both complex and simple routing policies. For example, a policy could be as simple as to accept all the routes advertised by another ISP at a NAP. Enforce Good Routing Engineering [The text describes how the route server can be used to dampen routing flaps.] End quote. Now it sounds to me like my private corrrespondent was saying that the routing registry was only a data base. That is a source where some could go to ascertain information about someone else's routing. Period. End of discussion. Routing would be done on the basis of bilateral peering agreements between individual providers connected to the NAPs. However, the text I have quoted from the R. ARBITOR'S pages seems to say something quite different - namely that ISP's at a NAP could have a single peering session with the route server there instead of having an individual peering session for every other attached router. If true it seems like this would indeed end most of the strains and stresses on the backbone routers of service providers discussed here several weeks ago under the links on the blink thread. Yet the route server answer won't work if everyone doesn't cooperate with it and provide their routes to it. Bill Manning's nanog post talks with frustration about a large provider that is NOT cooperating with the routing: Many people do register in the IRR. Those that don't, won't for a variety of reasons. For some, there is an unwillingness to trust a thirdparty operator coupled with no desire to run a portion of the registry in-house. When these two conditions are found in a large-scale provider, the concept and implementation of the Internet RR are frustrated to the extent that the non-participating provider becomes increasingly unreachable/understandable. They are relegated to peridoc public postings to mailing lists for definitions of their routing policies. The large scale provider he is talking about, it seems quite clear is Sprint. Question are MCI, PSI, UUNET and ANS in complete cooperation with the Routing Arbiter? Could one effectively run complete peering sessions with each of them and with smaller ISPs by a single connection to a route server?? If the answer is yes and this is not happening what is preventing it? Route Server users could run separate sessions with sprint presumably. Now Bill points out that isps would have to obtain peering agreements with others and that this process would be separate and apart from the operation of the route server which just reflects the individual peering agreements. (So in this sense the private assertion of the IETF figure is also correct.) Is the answer that the router server concept will necessarily fail if it does not get complete cooperation from **ALL** the top tier providers? If so, and IF it could really solve the resource constraints talked about in links on the blink, Sprint's apparent boycott of the concept and its service would seem to be a great shame. ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************

6 8

Topics for NANOG
by Susan R. Harris 22 Dec '95

22 Dec '95

Greetings - here are the presentations we're planning so far for NANOG, to be held Feb. 15-16 in San Diego: --Data over cable and the @Home network --Internet traffic and routing studies --internetMCI presentation --IPv6 auto-configuration --New PacBell ATM switch architecture --DVMRP/PIM pilot project --RA update Are there other topics you'd like to hear about? ------------------------------------------------------------------------ Susan R. Harris, Ph.D. Merit Network, Inc. srh(a)merit.edu Phone: (313) 936-2100 Fax: (313) 747-3185 ------------------------------------------------------------------------

1 0

Statistics on five interconnection points
by Dun Liu 21 Dec '95

21 Dec '95

The Routing Arbiter collects network statistics at the AADS, MAE-East, MAE-West, PacBell, and Sprint interconnection points. Public available reports include: Ping Delay/Packet Loss (reported monthly). BGP Peering: reports the number of update packets received by route server from each peer, and that peer's down/up information. (daily) System Uptime: reports route server uptime (monthly) Free Virtual Memory and CPU Usage: report the usage of virtual memory and CPU at route servers (daily). More reports will be added, such as tcp data packet retransmission, which will be compared to the ping packet loss The reports are at http://www.ra.net/~ra/statistics/ Comment are welcome. The entire work is the effort of Dun Liu, Bill Norton, Susan Horvath and Susan Harris. Dun Liu

1 0

Re: Service Problems
by Vadim Antonov 21 Dec '95

21 Dec '95

Now, that i'm not in the ISP business -- *all* large ISPs have the same "small" problem, namely the complete lack of understanding of the current workforce market by the management. There are only few people in the world who really know how the global routing works, and some of them already worth more than average Joe Banana telco tech will make for his entire life. Needless to say that they don't work for telcos, so those who still do have something to think about. In my practice, leaving a large ISP by members of engineering or operational staff causes rather steep increases in their income. On the other hand, engineers having compensation bigger than their managers is something unheard of in the telco corporate culture, and so is trusting engineers to do planning, without the "benefit" of last-year-plus-five-percent beancounting. Those who stay are either young enough to work just for fun, or have other reasons (immigration status, etc) to stay. Of course, incompetents tend to stay till pensions. --vadim PS Although i post from a Sprint accound i do not work or speak Sprint. >From list-admin(a)merit.edu Wed Dec 20 02:53:59 1995 Received: from merit.edu (merit.edu [35.1.1.42]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA27552 for <avg(a)titan.sprintlink.net>; Wed, 20 Dec 1995 02:53:58 -0500 Received: from pike.ixa.net (nikm(a)pike.ixa.net [199.242.19.1]) by merit.edu (8.6.12/merit-2.0) with ESMTP id CAA22222 for <nanog(a)merit.edu>; Wed, 20 Dec 1995 02:19:40 -0500 Received: (from nikm@localhost) by pike.ixa.net (8.7.3/8.6.11) id XAA13404; Tue, 19 Dec 1995 23:15:57 -0800 (PST) Date: Tue, 19 Dec 1995 23:15:57 -0800 (PST) From: Nikos Mouat <nikm(a)ixa.net> To: William Allen Simpson <bsimpson(a)morningstar.com> cc: nanog(a)merit.edu Subject: Re: Service Problems In-Reply-To: <4648.bsimpson(a)morningstar.com> Message-ID: <Pine.SUN.3.91.951219230848.13375B-100000(a)pike.ixa.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: R > On the other hand, I have been very pleased with MCI NOC. Yes, MCI has > some problems too, but they even CALLED BACK to let me know when > _another_ provider (PSI) had fixed the problem that I reported, rather > than me trying again every 10 minutes to see if it was fixed yet. That > kind service overwhelmed me with joy and brought tears to my eyes! If it makes you feel better, I put in a trouble ticket with MCI approx 29hours ago. it was not a complete outage, but the problem i was trying to talk to a tech about had an hour or so prior caused a serious outage on my mci connection - I would prioritize it as important, not urgent. the person who took the trouble ticket asked me if it would be "ok to take the circuit down for testing" - the problem i was trying to get resolved was related to peering.. go figure.. I still haven't heard back from MCI.. UUNET on the other hand I managed to get a call through to a tech there immediately... I've given up on trying to get through to MCI.. I've had nothing but good experience with them on the physical circuit level.. and the routing guys installing the circuit were great.. but trying to get a [routing] tech on the phone for trouble issues just sucks.

2 1

Re: Sprint Service Problems
by Hank Nussbacher 21 Dec '95

21 Dec '95

On Wed, 20 Dec 1995 01:11:30 -0700 (MST) you said: >Time for me to jump on the bandwagon. > >We're a Sprint Customer. Right now we have a 256K fractional T1 line to >the net. We're tied to Stockton-7. "Our End" of the line is in Helena >Montana. > >For months now, I've been asking them why our ping times look like: >Sending 100, 32-byte ICMP Echos to 144.228.47.21, timeout is 1 >seconds: >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >Success rate is 100 percent (100/100), round-trip min/avg/max = >100/104/204 ms > >Note the 100 ms. I have NEVER seen it below 100 ms EVER. No matter what >the traffic, time of day, etc. Well, maybe I've seen it at 98 or 99 once >or twice. > >In theory, a round trip time should be two times the single direction >distance, which should be composed of the following two items: > >1) 256K maximum bitrate (amount of time to clock the bits out) - > 32 bytes * 8 bit bytes = 256 bit times > 256 bit times * (1/256,000) (one bit time) ~= 1 ms >2) Speed of Light Limit (The Rest) > In vacuum, light can travel 186 miles per millisecond. > Not sure how much it differs in fibre, but I figure that > even if you assume that its 150 miles per millisecond, > you can travel roughly 7000 miles in the remaining time (59ish ms). > >So, that puts my link 7000 miles away. Now I'm curious as to how they >have my line routed over 7000 miles. So I call up their INSC and ask who >I can talk to about this. I end up opening a trouble ticket, and >eventually the engineer I talk to say's that it is in the acceptable >limits for the distance of circuit, which they tell me goes from Helena >to Seattle and then to Stockton California in more or less of a straight >line between the points. According to my calculation there's about 1200 >miles of fiber there. Still 5800 miles short. > >I backed off after reading some papers on ping times versus maxumum >flow. That is until I had an outage last week caused by a Fiber Cut in >Texas. Now I'm mad. I supposedly have a line from Helena to Seattle >to California which somehow goes through Texas. After finally yelling loud >enough about either this cut not being my problem or my line isn't routed >where I was told it was, I finally got a manager or VP who was kind >enough to tell me that my line is routed through Arizona, and Texas, and >a couple of other places in what I call the "mideast", and then to the >Dakotas, through montana to the spokane (eastern washington) area, and >then back to Montana. Adding up the miles, I get about 4-5,000 miles. >I can believe that, with some switch latency. Here are some tests I have done at 256kb: Line From-to Medium 8000 octet 1000 octet 32 octet speed ping ping ping in seconds in seconds in seconds ----- ------------- ---------- ---------- ---------- ---------- 256kb Israel-Israel fiber .524 .068 .008 256kb Israel-Israel FR, CIR=0 .628 .144 .016 256kb Israel-USA satellite 1.096 .640 .572 256kb Israel-Europe fiber .576 .116 .052 For 32 octets and 100ms - that is twice the rate we get with a fiber link from Tel-Aviv to Geneva - a few thousand miles. Hank

1 0

Wayward Cables
by Jeff.Ogden＠um.cc.umich.edu 20 Dec '95

20 Dec '95

Bill Simpson does not have his facts on the fiber cut to the old NSFNET NOC in Ann Arbor quite right. There was a cut and the NOC was cut off which wasn't good, but it was not the case that separate links were purchased to avoid that completely. We knew that there was some risk depending on where cuts took place. As I remmeber this happened twice in the 7+ years of the NSFNET agreement (two times to Michigan). -Jeff Ogden Merit

1 0

subscribe
by Benham Malcom 20 Dec '95

20 Dec '95

1 0

Wayward Cables
by William Allen Simpson 20 Dec '95

20 Dec '95

> From: "Forrest W. Christian" <forrestc(a)imach.com> > That is until I had an outage last week caused by a Fiber Cut in > Texas. Now I'm mad. I supposedly have a line from Helena to Seattle > to California which somehow goes through Texas. Reminds me of when the entire NSFnet went down because both the primary and backup links (purchased deliberately to be separate) coming to the NSF NOC were cut -- far to the north, on supposedly southeast and southwest bound links! Needless to say, the two links weren't supposed to go over the same fiber (by definition), and going by way of Midland was a long way out of the way! (Not as far as Texas, though.) Maybe every contract needs a clear picture of where the links are actually located! What can NANOG, as a group, do about this problem? Do we need to form yet another consortium to coordinate link purchases for NA? Might save some money, too.... Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Service Problems
by William Allen Simpson 20 Dec '95

20 Dec '95

Gosh, and I thought that it was PSI that had these characteristics. No, I don't subscribe to PSI, but some of my clients/contacts do. Not long ago, their Detroit switch had been down for 4.5 hours (and thereby a big chunk of the midwest, since they refuse to peer at NAPs), and they hadn't even noticed! I had to _tell_ them to ping it, and the address to ping. (They did know how to ping.) On the other hand, I have been very pleased with MCI NOC. Yes, MCI has some problems too, but they even CALLED BACK to let me know when _another_ provider (PSI) had fixed the problem that I reported, rather than me trying again every 10 minutes to see if it was fixed yet. That kind service overwhelmed me with joy and brought tears to my eyes! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2