- NANOG - lists.nanog.org

Re: Links on the blink - what will/should mci & sprint do?
by sob＠academ.com 19 Nov '95

19 Nov '95

Sean Doran writes: > No, what a disaster would mean is replacing backbone 7500s > with 7000s Sean, are there actually backbone 7500s in production? I thought that was yet to come. Did I misread something here? -- 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: Links on the blink - reprise
by Jeffrey P. Oliveto 19 Nov '95

19 Nov '95

Paul; You state: At 05:47 PM 11/17/95 -0500, Sean Doran wrote: > >There are substantial disadvantages, too. > >In order to take advantage of the greater >port-density(-per-dollar) on FR switches right now, the >end user has to use FR, which is not always practical >or desirable. > One of the reasons why end users find frame-relay undesireable is that they cannot be assured that their provider is not grossly oversubscribed on PVC-per-port density. When you buy a T1 private line, you can be assured that you're not sharing it with 120 other end-users. :-) DS3/DS1 Backbone/Trunk capacity planning principles, whether across a Frame Relay Backbone or Cisco 7000 hdlc trunk network are still the same. It's just as easy to over configure DS3/DS1 Cisco HDLC trunks as Frame Relay trunks. Potentially at issue here is not Frame Relay networks as a transport but that a Cisco 7000 can not scale properly to support 120+ end-users. :-) Modern Frame Relay switches: 1) have sub-msec latency 2) can support multiple trunks at DS3+ (to include ATM) 3) are not burdened with processing any of the IP layer 3 nor routing overhead 4) because of 3 have a cost per port that is 300 to 400% less than a Cisco 7000 5) can have it's backbone shared across multiple services thereby reducing both capitalization and bandwidth expense 6) allow ISP to pass the cost savings on to customers ----------------------------------------------------------------------------- Jeff Oliveto | Phone: +1.703.760.1764 Sr.Mgr Opns Technical Services | Fax: +1.703.760.3321 Cable & Wireless, Inc | Email: joliveto(a)cwi.net 1919 Gallows Road | URL: http://www.cwi.net/ Vienna, VA 22182 | NOC: +1.800.486.9999 -----------------------------------------------------------------------------

1 0

Re: Links on the blink - what will/should mci & sprint do?
by Sean Doran 19 Nov '95

19 Nov '95

icm-dc-3.icp.net is a 7505, as is one of its counterparts on the other side of the Atlantic. All routers in Kansas City, Seattle, Cheyenne and Atlanta are 7513s, although they are not yet up and operational. There are a largeish number of 7513s deployed in another parallel network that is engineered out of our group. No points for guessing what that's for. :) Sean.

1 0

Links on the blink - reprise
by Gordon Cook 19 Nov '95

19 Nov '95

People are starting to tell me that the way out of smashing into the brick wall at 60 miles and hour that the Links on the Blink discussion was worrying about a week ago, is to take cascade or other frame relay switches for the national service providers backbone topology and push routers out to spoke and wheel hubs at the perimiters of the back bone where traffic sent on the backbone at the data link layer (2) can pop out and into the appropriate router for layer 3 routing to the final destination. PSI and UUNET have apparently been following this strategy with their backbones for some time. Netcom has also come on board. Its advocates say that this combination can scale and avoid the 60 mile per hour brick wall crash. Are they right? And if so why aren't sprint and MCI running in this direction and away from purely router based networks as fast as they can? If they are why are they wrong? Where does this architecture fail? If it fails. ******************************************************************** Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 The COOK Report on Internet Non Profit. $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 Newly expanded COOK Report Web Pages http://pobox.com/cook/ ********************************************************************

7 7

Re: Links on the blink - reprise
by Paul Ferguson 19 Nov '95

19 Nov '95

At 05:47 PM 11/17/95 -0500, Sean Doran wrote: > >There are substantial disadvantages, too. > >In order to take advantage of the greater >port-density(-per-dollar) on FR switches right now, the >end user has to use FR, which is not always practical >or desirable. > One of the reasons why end users find frame-relay undesireable is that they cannot be assured that their provider is not grossly oversubscribed on PVC-per-port density. When you buy a T1 private line, you can be assured that you're not sharing it with 120 other end-users. :-) - paul

7 7

Re: Links on the blink - reprise
by Paul Ferguson 19 Nov '95

19 Nov '95

At 06:56 PM 11/18/95 -0600, Alan Hannan wrote: > >] Yes, that is true but most ISP's in my area are overselling 100 X or >] more. Sure I mux 4 T1 FR to 1 T1 port and oversell my bandwidth, but all >] of my links have at least 20% free on them during our peek. > > What is your sample interval? Cisco's 5 minute average? > > 80% utilization at 5 minute samples means it is very likely the > lines are choked a good portion of that time. > >-alan > > Peek. A Freudian slip. :-) - paul

1 0

Re: Links on the blink - what will/should mci & sprint do?
by Sean Doran 19 Nov '95

19 Nov '95

| COOK: does this mean that there is some way to get the cisco to behave | like the cascade switch I asked about?? If not what in general does it mean? No, this means that we should be able to squeeze every last drop of bandwidth out of the 7500, such that 4x+ or so worth of OC3s can work in the same chassis without difficulty. | Finally you said if the 7500 doesn't perform well then you might have to | do the redesign I asked about.... meaning going to an atm switched | backbone with routers at the periphery of the backbone?? Over my dead body. The nicer bits of Curtis's last message very clearly and correctly indicated the drawbacks in using ATM or any other L2 protocol. Perhaps he or someone else can put it into slightly less technical terms. No, what a disaster would mean is replacing backbone 7500s with 7000s and doing lots of thinking about really ugly kludges to deal with scale beyond the bandwidth limits of the 7000 series backplane and lots of screaming at Cisco to make the 7500 work at least as well as the 7000+SSP. (We have the latter committment from them already, btw.) Many possibilities exist that don't entail going with ATM, or even necessarily with some non-Cisco switching engine, or some L2 protocol sandwiched between the physical lines and IP, all of which would work in principle. As I think I have said earlier, the value of Cisco is much more in its software than in its hardware; I like Cisco because I know that IOS can be made to work the way I need it to, which is more than I can say for any vendor of any other platform. Cisco does weird things with respect to hardware that sometimes gets annoying or frustrating, but as Melinda Shore's .signature (after Hippocrates) reminds the world: "software longa, hardware brevis". Sean. P.S.: Actually, the quote from Hippocrates's _Aphorisms_ is pretty apt to this discussion: "[Of medicine] The life so short, the art so long to learn, opportunity fleeting, experience treacherous, judgement difficult." Maybe Dave Mills should consider storing this with his jaguar.txt file. :-)

1 0

Re: Links on the blink - reprise
by Hank Nussbacher 18 Nov '95

18 Nov '95

Look up the Nov 6th issue of Communciations Week International. Article entitled "Internet providers move to frame relay" by Richard Karpinski and Kenneth Hart. Discusses how PSI, UUnet and Netcom have moved to B-STDX 9000 frame relay switches by Cascade. Hank

2 1

Re: Links on the blink - reprise
by Paul Ferguson 18 Nov '95

18 Nov '95

At 07:30 AM 11/18/95 -0500, Mike O'Dell wrote: > >don't confuse the link encoding with back-haul design > Don't confuse backhaul design with excessively high concentrations of PVCs, grossly oversubscribed in ratio of aggragate ingress bandwidth. If you don't drop the bits on ingress, you at least stand a fighting chance of getting them (the bits) onto the backbone in the first place. :-) >if the network is deeply over-subscribed, you will drop packets. >the only question is "where?" > Where indeed. >whether the link uses F/R-1490 framing or cisco HDLC doesn't change >that. > This has nothing at all to do with it. Regardless of the frame-relay encapsulation, the fact that one can oversubscribe at ingress exists and lends itself to what Vadim calls 'too may points of indirection'. A private line only has two end-points (let's not discuss imuxes). The possibility of sloppy or careless engineering is just a tad higher when building frame-relay networks. This does not mean that sloppiness can't be avaoided; it certainly can. Just a thought, - paul

1 0

Re: Links on the blink - reprise
by Paul Ferguson 18 Nov '95

18 Nov '95

At 05:45 PM 11/17/95 -0700, Dave Siegel wrote: >> One of the reasons why end users find frame-relay undesireable is >> that they cannot be assured that their provider is not grossly >> oversubscribed on PVC-per-port density. When you buy a T1 private >> line, you can be assured that you're not sharing it with 120 other >> end-users. :-) > >Nor can you know that with a Dedicated line, that the other side doesn't feed >into a 2501 into a collision-ridden Boca 10baseT hub, into a Welfleet bridging >over Frame-Relay-over-ATM at 1.5Mbps simplex speeds into an over-committed >4Mbps port speed on the other side. > >i.e., the fact that your buying a leased line to connect and running HDLC >over it doesn't count for anything. When it comes right down to it, customers >can't really be reassured of anything. > Quite true. Appearances can be deceiving. :-) I was just reiterating (what I thought to be) the obvious. >But then, nobody expects the customer to realize this, right? > >Dave > Um, I won't touch this one. - paul

1 0