- Test - lists.nanog.org

Re: MCI [ATM overhead]
by Kent W. England 22 Mar '96

22 Mar '96

At 03:09 PM 3/21/96 +0800, Vadim Antonov wrote: > ... (as ATM does not handle >levels of overcommitment found in IP backbones now). > > >--vadim > > Vadim; I think that statement, as I interpret it, could only apply if you are running IP over a rate-controlled ATM backbone (either CBR or VBR QoS). Nobody in their right mind does that if they have an alternative. ATM responds to "overcommitment", if you mean "excess offered load", by shedding that load either in the middle of the backbone at the bottleneck if you are running IP over UBR or at the edge of the network if you are running a proprietary ABR. IP routers respond to excess offered load by shedding that load in the middle of the backbone, since IP router QoS is essentially the same as ATM UBR. In this sense, with ATM you have two choices for handling overcommit- ment (if your ATM switch vendor has a proprietary ABR) but with routers you have only one. --Kent

1 0

OOPS! Cisco OC3 retraction!
by Carl Payne 22 Mar '96

22 Mar '96

Holy guacamole! Hmm...where to begin. Well, first, let me apologize for my rudeness. I meant to insert a little smiley (no, really, I did!) and I did not. My post was not meant to be so hostile. Second, let me apologize for my ignorance. On our entire network, only 2 of our routers are 4500s and both are outfitted with 2 ethernet and 8 serial ports. I had no idea there was ALREADY an OC3 interface available for that router, nor did I plan on learning such because we've moved on to bigger things. FWIW, I apologize. Had I flipped to pp139 of this year's Ciscoble, I would have spared my damaged soul the embarrasment of trying to be funny. Doggonnit, and I thought I was going to be able to give up being a jerk by Christmas. Carl

1 0

Re: mae-west congestion
by lance＠nsipo.arc.nasa.gov 22 Mar '96

22 Mar '96

Yes, agis is on the MFS side and mci+sprint is on the nasa side, though it is my understanding that mci put in a line on the mfs side as well. I believe ANS has pulled a line in on the mfs side as well. The two sides of the mae-west are connected by an OC-3. At 11:43 PM 3/21/96 -0800, Nikos Mouat wrote: > >On Thu, 21 Mar 1996, Peter Kaminski wrote: > >> >What I don't understand is why that has _stayed_ saturated... it seems to me >> >that some of the big players would have rerouted their traffic by now to avoid >> >subjecting it to this, which would also have the side effect of causing the >> >problem to, at least for the short term, go away. >> >> ...or why MFS hasn't installed a Gigaswitch there, or whatever. We're seeing >> 20% - 30% packet loss through AGIS to MCI and Sprintlink during the day, and >> it's not fun. > >isn't agis on the mfs side and mci+sprint on the nasa side? (i know that >net99 was/is on the mfs side, but i dunno if agis is using their cage or >have a different one) > >are the two 'sides' of mae-west still connected by only a ds3? > >/nm > >

1 0

Re: NET99 sabotages IGC's routes NOW: The facts
by Peter Kline, Sr. Network Engineer 22 Mar '96

22 Mar '96

At 10:21 PM 3/15/96 -0500, Joel Katz wrote: > > IGC (Internet Gateway Connections, an ISP in Florida that was >multihomed between NET99 and MCI) just had an unexpected outage lasting in *The lie:* >excess of an hour. This outage was deliberately engineered by AGIS/NET99. *The fact:* IGC's routes were pulled from the Net99 net within 90 minutes of their being turned off *at IGC's request*. >First, a little history: > > IGC's first 'Net T1 was to NET99. Instead of connecting us >directly to their backbone (as we had expected) they connected us to >Netrunner (one of our competitors). Netrunner/NET99 only has a single T1 >out of Miami (to Atlanta) and as a result, our throughput was awful and >we obtained an additional T1 to MCI. This was common in the Net99 network. I guess it worked OK at first, but it didn't scale as customers grew. There was a tremendous hoo-ha back when AGIS bought Net99 because some people who were in mid-install were redirected to AGIS. That hurt the pending customers, but it helped the existing customers like IGC as much as it could. *The lie:* > A few days ago, someone at Netrunner got upset with someone at >NET99/AGIS and shut off _our_ service. For some reason (we strongly >suspect a configuration error at NET99) our traffic failed to reroute >over our MCI T1 for several hours. (They have a habit of broadcasting >static routes to route around outages, thus completely screwing their >multi-homed customers.) *The truth:* The referenced disconnection did occur, and was restored. This kind of problem is a very real danger of the way Net99 colocated in certain cities. That's why AGIS only colocates in POP's and private spaces. And in the event that a customer is dually homed and not running BGP, it's incumbent upon the customer to make sure that *both providers* are aware of the fact and properly setting local prefs. IGC did not do that and bears full responsibility for any failure to route properly during an outage. Aha: a true statement: > We asked AGIS for a one month refund to compensate us for our >losses due to the sabotage. Instead, they issued us a _one_day_ credit. Ah, another true statement: >We got upset, both with the ability of our T to pass traffic, with >NET99's continual routing problems, with NET99's backbone being >disassembled from under us, and with NET99/AGIS's continual delays in >migrating us to the AGIS network. We asked them to discontinue our service. True, but we certainly wouldn't have left them without a circuit. We've tried mightily to install a new circuit to their premises, and ran into a b8zs facilities problem. We could have installed it AMI as a temporary measure with no problem. *Another LIE* > They did. They also deliberately and maliciously began >broadcasting more specific routes for the individual class C networks in >our CIDR block. (We confirmed this with MCI.) *The truth:* Over the months various static routes have been installed by various people on Net99 to route around some problems (a practice which predates our purchase). You run into some curious situations like a static on a Chicago router pointing to Phoenix. In this case, there were statics of differing prefix lengths on different routers. The aggregate address statement got pulled, and we didn't catch the more specifics on another router. As soon as we found out what happened, we pulled them. In fact, we pulled them while we were on the phone with MCI so that they could confirm that they were gone. The statement of malicious intent is untrue and libellous and must be withdrawn immediately by Mr. Katz. [...] *Another LIE* > I contacted MCI again and they contacted AGIS/NET99 with the >ultimate threat being for MCI to stop carrying AGIS' traffic if they would >not cease broadcasting the bogus routes. Shortly after being contacted by >MCI, AGIS/NET99 stopped announcing the bogus routes to MCI, but continued >advertising these routes to their other peers at the NAPs. Nope. Like I said, MCI didn't threaten us at all, and worked with us to see that the routing was correct. Net99 isn't announcing those routes anywhere. Both AGIS and Net99 announce all routes at all exchange points to all providers in compliance with our peering contracts. If MCI had called back and said, "we still have a problem," we'd work with them until it was taken care of. > > Fortunately, MCI was able to reconfigure our access lists at their >router to allow us to broadcast competing more specific routes for each >individual class C in the CIDR block. Thus (more or less) restoring IGC's >net connectivity. More specifics aren't competing. They take precedence. Sometimes it's better to be silent and thought dumb... Ah, more libel: > NET99's deliberate, malicious actions are contrary to the very >spirit of the Internet. They resulted in DALnet (the third largest IRC >network) being split to ribbons, depriving 2,500 people of the ability to >converse with each other and cutting off DALnet's security and access >control system which is hosted here. Another retraction required ASAP, Joel. AND NOW, here's what Joel left out: IGC called our NOC up, screaming, the night this occurred, and "put us on notice" that "if we didn't disconnect our circuit to them immediately [we all know that phone companies do nothing immediately] they were going to flood ping [another Miami customer] until we did." We had no reason to disbelieve them so we did turn down the port, and had the routing unwound within a couple of hours, which isn't bad given the nonexistent notice and other things going on. In other words, Joel comes to the court of public opinion with unclean hands. Joel threatened an illegal act against another customer. Joel's righteousness rings hollow. Joel must recant immediately. > > Please excuse me if this is not the appropriate forum for discussing >this event. And this is weird. The sig and the FROM don't match. Is this all a joke? > > David Schwartz > Director of Network Services > Internet Gateway Connections > (954)-430-3030 > > _____________________________________________________________________ Peter Kline Senior Network Engineer| NOC 313-730-1130 AGIS - Internet Backbone Services | ///////////////////////////////////////////////////////////////////// "I knew exactly how he felt. Not so much banging the head against a brick wall as actively being attacked by a cliff." - Dick Francis in _Enquiry_

3 2

RE: MCI
by bajaj＠bellcore.com 22 Mar '96

22 Mar '96

> > The thought is not to increase the efficiency of SONET, but rather the > efficiency > of the edge device that fills the SONET frames. The drive to doing this > comes from > the emergence of "integrated SONET multiplexers" that accept native > traffic as > input, and output to a OC-n network. There is NO talk of changing the > STS payload > size or the 125us transmit time. Those parameters are fixed and > generally cannot > be manipulated. But, the actual payload (2340 bytes) can be completely > filled, thus > optimizing the *utilization* of the SONET. > > Like I mentioned, the project was focused on ATM and Frame relay. The > idea was to > provide the inetgrated SONET mux with information on the input traffic > protocol. Based > on the input protocol's cell/frame/packet size, the mux would attempt to > completely fill > a STS payload. There is a large amout of wasted bandwidth in today's > systems where > the STS is very much underutilized. This is because today's SONET > systems tie one > particular input to a specific STS. Optimization occurs by filling the > payload with cells/ > frames/packets from multiple sources that use the same protocol. In > essence, this > begins to treat SONET as a shared transport system rather than the > dedicated, virtual > point-to-point system that it is today. Of course, the source and the > destination of the > multiple sources would have to be the same for this to work. Gotcha. This seems to be the next step in the evolution of SONET transport systems, i.e. putting the muxing functionality in the same box as the switching/routing function. > You guess right. In telephony, carriers want to use every bit that can > possibly be used. > Brings to mind a project where a certain carrier actually sold the > protect channels on a > ring to a customer.... but that's another e-mail altogether ;-) > Actually, I hear that that practice is becoming more common. Depending upon the discount, I may choose unprotected transport, especially if I knew that my edge devices failed much more often than the carrier network. :-) Shikhar

1 0

RE: MCI
by Bharat Ranjan 22 Mar '96

22 Mar '96

>>Even if you increase the efficiency to 99+%, for bursty traffic like IP, >>are people going to wait til they have 95% link utilization before they >>increase their capacity? Of course not. Customers will be screaming >>long before then. While more efficiency is always better, will anything >>actually be gained by trying to squeeze an extra couple of percent out >>of SONET? (Though I can easily see how this would benefit telephony :-) ). > >>I also don't understand how this technique would help anything in a WAN. >>Even if you play games with the path overhead, the SONET regenerators >>and cross connects in the carrier infrastructure are section and line >>terminating equipment, respectively. They don't care what the path >>overhead looks like and will still be expecting 2430 byte frames. Thus, >>you would have to do some sort of "fragmentation" at the network edges. > >>It would also be interesting to see how they propose reconciling the >>fact that their frame time is no longer strictly 125 usec. > > >>Shikhar The thought is not to increase the efficiency of SONET, but rather the efficiency of the edge device that fills the SONET frames. The drive to doing this comes from the emergence of "integrated SONET multiplexers" that accept native traffic as input, and output to a OC-n network. There is NO talk of changing the STS payload size or the 125us transmit time. Those parameters are fixed and generally cannot be manipulated. But, the actual payload (2340 bytes) can be completely filled, thus optimizing the *utilization* of the SONET. Like I mentioned, the project was focused on ATM and Frame relay. The idea was to provide the inetgrated SONET mux with information on the input traffic protocol. Based on the input protocol's cell/frame/packet size, the mux would attempt to completely fill a STS payload. There is a large amout of wasted bandwidth in today's systems where the STS is very much underutilized. This is because today's SONET systems tie one particular input to a specific STS. Optimization occurs by filling the payload with cells/ frames/packets from multiple sources that use the same protocol. In essence, this begins to treat SONET as a shared transport system rather than the dedicated, virtual point-to-point system that it is today. Of course, the source and the destination of the multiple sources would have to be the same for this to work. You guess right. In telephony, carriers want to use every bit that can possibly be used. Brings to mind a project where a certain carrier actually sold the protect channels on a ring to a customer.... but that's another e-mail altogether ;-) mm mm sssss nnnnnn * Bharat Ranjan * m m m s nnnnnnn * Network Engineer * m m m sssss nn nn * Microsoft On-Line Services * m m s nn nn * (206)-936-0471 * m m sssss nn nn * bharatr(a)microsoft.com * ******************************************************* * The opinions/ideas in this memo are not necessarily * * those of Microsoft Corp. * ******************************************************* >

1 0

mae-west congestion
by matthew＠scruz.net 22 Mar '96

22 Mar '96

If you take a look at http://ext2.mfsdatanet.com/MAE/west.ames.overlay.html you find that the Ames FDDI ring is totally saturated. Now, that means that anyone who's trading traffic over on that side, or between Ames and San Jose, is getting really really lousy performance. What I don't understand is why that has _stayed_ saturated... it seems to me that some of the big players would have rerouted their traffic by now to avoid subjecting it to this, which would also have the side effect of causing the problem to, at least for the short term, go away. I can't do much about this myself, since my router isn't one of the ones generating huge amounts of traffic over on that ring, but surely someone on this list is in that position... and the major contributors to this traffic must be getting complaints from their own customers about how their packets are being routed via a lossy interchange point. -matthew kaufman matthew(a)scruz.net

7 6

RE: Address "portability"
by Jim Fleming 21 Mar '96

21 Mar '96

On Thursday, March 21, 1996 7:13 AM, Bill Manning[SMTP:bmanning@isi.edu] wrote: @> @> @> What is the general consensus of this group regarding the "portability" of @> addresses in the 204/8 and 205/8 range? @> @ @ All address prefixes are portable. Their routability by any @ given transit provider is always suspect and varies from time @ to time. @ This nomenclature has been foisted on the unsuspecting by well @ intentioned people. This idea fosters the myth of global @ reachability for any given prefix. @ @-- @--bill @ @ @@@@@@@@@ WWW.ISI.EDU Has a New IP Address! ------------------------------------------------------------------------ As of March 21, 1996 10:30PDT, the ISI web server has a new IP address. If you have reached this page, it is because of one of the following reasons: 1.You have referred to www.isi.edu by its IP address, which has changed to 128.9.176.20, 2.You have referenced www.isi.edu and your Domain Name Service still has the old IP address. If this symptom persists after a resonable amount of time, please contact your system administrator with the information from number 1. 3.You have made some other reference that does not point to our new web server. To get to our new server, use: http://www.isi.edu/ if you landed here using the old IP address or http://128.9.176.20/ if you've already tried www.isi.edu (see reason number 2 above). Please make a note of this change. ------------------------------------------------------------------------ Comments and Questions regarding this site may be sent to action(a)isi.edu. @@@@@@@@@@ # ping www.iana.org PING VENERA.ISI.EDU (128.9.176.32): 56 data bytes 64 bytes from 128.9.176.32: icmp_seq=0 ttl=246 time=90.023 ms 64 bytes from 128.9.176.32: icmp_seq=3 ttl=246 time=80.949 ms 64 bytes from 128.9.176.32: icmp_seq=4 ttl=246 time=85.716 ms 64 bytes from 128.9.176.32: icmp_seq=5 ttl=246 time=80.661 ms 64 bytes from 128.9.176.32: icmp_seq=6 ttl=246 time=86.847 ms ^C --- VENERA.ISI.EDU ping statistics --- 7 packets transmitted, 5 packets received, 28% packet loss round-trip min/avg/max = 80.661/84.839/90.023 ms @@@@@@@@@@ Portability in action....it looks like IANA has moved 12 doors down the street... -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

1 0

Re: cisco OC3 interfaces
by Dave O'Leary 21 Mar '96

21 Mar '96

Hi Dave, We've certainly been known to do some pretty silly things before, and some would say that a lot of things we're doing now are pretty silly :-) Regardless, an non-disclosure agreement is a non-disclosure agreement. We work very hard internally to avoid "leaking" information between the various providers we are under non-disclosure with, and we expect the customers who we work with under an NDA to also take the NDA seriously. While it might make complete sense that we are/should be working on a particular product or feature, that doesn't mean that we are, and details like how close we are to delivering a particular product or its specific features, etc. could clearly be of use to our competitors - which is why we execute an NDA. Thanks, dave

2 1

RE: MCI
by bajaj＠bellcore.com 21 Mar '96

21 Mar '96

> Last year, I was involved with some vendor work that was being done to > optimize the > SONET payload for various protocols. In particular, the 'growth' bytes > Z3, Z4, and/or Z5 in > the SONET Path overhead would be used to optimize the payload size based > on the > protocol being used. The thought was that such an optimization would > take place at the > "edge" of the network, where local traffic is passed to a WAN, via > SONET. ATM and > Frame Realy were being focused on in particular, especially with the > concatenated > (OC-Nc) payload. I was told that IP has now been added to the list of > protocols that > SONET would optimize/support. If this work comes out as a SONET > standard, it would > be a great plus when using OC-3c interfaces on routers. Why is SONET a problem? An STS-3c has 2430 byte frame of which 90 bytes are management overhead. This is a fixed efficiency of 96.3%. Even if you increase the efficiency to 99+%, for bursty traffic like IP, are people going to wait til they have 95% link utilization before they increase their capacity? Of course not. Customers will be screaming long before then. While more efficiency is always better, will anything actually be gained by trying to squeeze an extra couple of percent out of SONET? (Though I can easily see how this would benefit telephony :-) ). I also don't understand how this technique would help anything in a WAN. Even if you play games with the path overhead, the SONET regenerators and cross connects in the carrier infrastructure are section and line terminating equipment, respectively. They don't care what the path overhead looks like and will still be expecting 2430 byte frames. Thus, you would have to do some sort of "fragmentation" at the network edges. It would also be interesting to see how they propose reconciling the fact that their frame time is no longer strictly 125 usec. Shikhar

1 0