- Test - lists.nanog.org

RE: MPLS VPNs or not?
by Kavi, Prabhu 08 Aug '01

08 Aug '01

Absolutely right, which (along with TE on IP routers) is why I think ATM has outlived its usefulness in the backbone of an ISP network. Prabhu > -----Original Message----- > From: Travis Pugh [mailto:tdp@discombobulated.net] > Sent: Wednesday, August 08, 2001 12:40 PM > To: Kavi, Prabhu > Cc: nanog(a)merit.edu > Subject: Re: MPLS VPNs or not? > > > > At one time, UUNET's traffic was simply outrunning the > > ability of L3 routers to keep up. Their choices were to: > > That does invite a companion observation: at one time, I > could reasonably > guess that their traffic was outrunning the ability of Layer > 2 ATM switches > to keep up, as ATM switch vendors have lagged well behind the > curve in OC48 > and OC192 trunk capability, and IP router vendors haven't > even put OC48 ATM > linecards on the market. > > -travis > >

1 0

RE: MPLS VPNs or not?
by Kavi, Prabhu 08 Aug '01

08 Aug '01

> -----Original Message----- > From: Fletcher E Kittredge [mailto:fkittred@gwi.net] > Sent: Wednesday, August 08, 2001 11:35 AM > To: Kavi, Prabhu > Cc: 'Vadim Antonov'; Christian Kuhtz; nanog(a)merit.edu > Subject: Re: MPLS VPNs or not? > > > On Wed, 8 Aug 2001 08:56:53 -0400 "Kavi, Prabhu" wrote: > > I guess the real question should be how much market cap did other > > companies lose because of certain people's zealotry? Any answers > > Vadim? > > Prabhu; > > What evidence do you have that: > > 1) UUnet is/was a success, My take is that the best measures of success is market acceptance and profitability. Not a perfect measure, but certainly beats alternatives like academic debates like protocol X is evil, or service provider Y sucks. If protocol X is evil, ISPs will not use it, or those that do use it will fail. If protocol X was useful but has outlived its usefulness (e.g. ATM in the core), ISPs will no longer use it. [Note that I am not against academic discussions. However they are only useful until market deployment has proven them right or wrong. The people who are still against ATM on religous grounds should get over it.] If service provider Y sucks, then customers will leave it. Neither happened to UUNET. > > 2) if it was a success, the determining factor was its use of ATM, > rather than its first mover advantage, > financial/management stucture, > industry trends, etc. For example, UUnet used ATM because that was > what the bellheads would sell them. At the time, there was no > alternative to the bellheads. First of all, UUNET got a lot of things right. As Craig said, they were an excellent ISP. Those factors you mentioned were all important. However a significant roadblock in any one area can slow down your growth. At one time, UUNET's traffic was simply outrunning the ability of L3 routers to keep up. Their choices were to: 1. Adapt to another network architecture that scaled 2. Have a poor network that did not scale, and therefore would drop lots of customer traffic 3. Refuse customers that wanted to sign on. Taking positions 2 or 3 would have caused them to lose market share. They took position 1 and, combined with doing many other things right, maintained their growth. And as I already mentioned in another message, UUNET's network ran directly over TDM. I don't know what you mean about what the Bellheads would sell them. Prabhu > > regards, > fletcher >

3 2

Blocking CODE RED IOS NBAR CCO Tech Tip
by Scott Frisby 08 Aug '01

08 Aug '01

CCO official release on blocking code red w/ IOS NBAR - http://www.cisco.com/warp/public/63/nbar_acl_codered.shtml

2 2

Re: MPLS VPNs or not?
by George William Herbert 08 Aug '01

08 Aug '01

Ken writes: >[...] >Men could obtain the power, gratification and recognition they need thru >killing something, rathing than sending email. Peering policy dispute resolution by gladitorial combat? -george william herbert gherbert(a)retro.com

2 1

Re: MPLS VPNs or not?
by Dave Israel 08 Aug '01

08 Aug '01

On 8/7/2001 at 15:50:00 -0400, Fletcher E Kittredge said: > > 1980 X.25 Still in use worldwide, 21 years later. > 1984 OSI Usable parts adapted for IP use. > 1991 ATM Running DSL circuits everywhere (though not for much longer, at this rate.) Not to mention voice and video, and even some IP backbones. > 2000 MPLS Yep. You missed Frame Relay, PPP, SONET, a bunch of other protocols, and making any sort of point... unless you're trying to say some protocols do better than others, which is a given. -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

7 6

RE: MPLS VPNs or not?
by Kavi, Prabhu 08 Aug '01

08 Aug '01

I did not work *for* UUNET either. However, I did work for Cascade *at* UUNET as on on-site consultant sometime in 1995. I worked with their network engineers in analyzing traffic patterns, performing network design, and looking at network costs. In addition, I followed their network design closely from 1994-1998. I can definitely state that UUNET had its own separate Frame Relay and (later) ATM backbone network that they did not share with Worldcom's Frame Relay/ATM network. UUNET's L2 switches were directly connected to T3 TDM and later OC-12 TDM links. Prabhu > -----Original Message----- > From: Craig Partridge [mailto:craig@aland.bbn.com] > Sent: Wednesday, August 08, 2001 9:19 AM > To: Kavi, Prabhu > Cc: nanog(a)merit.edu > Subject: Re: MPLS VPNs or not? > > > > In message > <6B190B34070BD411ACA000B0D0214E56CB8128(a)newman.tenornet.com>, "Kavi, > Prabhu" writes: > > >I don't think UUNET considered it a waste. UUNET could not have grown > >as quickly as it did during the mid to late 90s without L2 (Frame and > >ATM) technologies. Fortunately for them, they did not have > any pure IP > >only zealots that prevented the pragmatic use of other technologies > >in their networks. Otherwise they probably would not have been able > >to outrun the other ISPs. > > I know the history here pretty well (though since I was never employed > by UUNET, I'll probably get some of it wrong). It doesn't quite match > this description. > > UUNET was an excellently run ISP well before it starting doing the ATM > activity. It came (I suspect) from Rick Adams' days as a > struggling ISP, > competing against Govt subsidized regional networks, in the > 1980s. If you > look at their various SEC filings in their first few years, they're a > tightly run company. > > Once UUNET was acquired by Worldcom, UUNET had access to Worldcom's > network infrastructure, which was heavily ATM, and which UUNET had to > share with the Worldcom's (very lucractive) voice traffic. In that > context, there was a real cost to using bandwidth and UUNET had to use > account for its usage. > > Some other ISPs were/are in a different business model -- > they owned their > fiber runs, outright, and the question for them was whether to put run > ATM over that fiber, and subdivide the bandwidth of a single waveband, > or light two wavebands (one voice/one IP). I've seen the > marginal cost > analysis for that kind of decision, and it often favors two wavebands. > > Craig >

1 0

Static routes in an AS vs BGP advertised routes
by Murphy, Brennan 08 Aug '01

08 Aug '01

Suppose you had a scenario where your AS is multi-homed to two ISPs in, for example, 8 cities around North America. Every site is connected to both ISPs and all of your address space occupies a /19. To your ISPs, you advertise specific /24s in each city. In turn, each ISP advertises your /19 to the rest of the Internet. Everything is going along smoothly until an asteroid crashes into the data center of one of your ISPs in one of the cities. It causes extensive damage and a certain amount of hysteria but to you, it means that only one of your ISPs can truly reach your full /19. That is, the /24 you were advertising in that city is now only reachable via one of the ISPs. But the ISP taken out by the asteroid is still advertising the full /19. Under the circumstances (loss of life, hysteria, sub-optimal routing), would it be appropriate to ask the unfortunate ISP to create a static route on their network to push traffic destined for that particular /24 over to the other ISP's network? This way, the /19 advertisements can be maintained and when traffic destined for that one /24 reaches the asteroid ISP, it can get passed over to the non-asteroid ISP. The route wouldnt be advertised to other carriers.....just used to make sure traffic reached the correct final destination. Will ISPs make these types of accommodations? Suppose the reason was less unexpected than an asteroid. For example, suppose you open a site in a 9th city, but only one carrier is available there. In other words, are ISPs reluctant to slap in static routes for every customer who comes along with some sob story about poor planning and/or unexpected growth? Your comments on this theoretical scenario are much appreciated. -BM

3 2

Re: MPLS VPNs or not?
by smd＠clock.org 08 Aug '01

08 Aug '01

| The other thing that is worrying is how many telco dinosaurs have | come out of their hiding places claiming to be gurus on all things | IP and MPLS because to them it looks like a telephone switch. MPLS did two things very well: 1. it killed Ipsilon and their traffic-driven shortcut routing 2. it put the final nail in the coffin of ATM Unfortunately, the side-effect of #2 is that there are lots of ATM bellheads who have decided that the variable-length "cells", the SVC model and the statmux gain are superior to ATM + ABR (no contest), that therefore they should fully embrace and extend MPLS. Fortunately, they haven't done this well enough to confuse enough non-bellhead people into really _using_ this stuff for long. Remember, in Imperial China small feet were so desirable that women's feet were bound to keep them from growing normally, sometimes to the extent that they became unable to stand or walk without assistance. These were the sexiest "small-foots". In telco school, people's heads are bound to keep them shaped like the pre-divestiture AT&T logo, and the sexiest "bell-heads" are sadly unable to think without assistance. Arguing that MPLS is the ONLY solution to VPNs or that (with or without MPLS) RFC 2548 is the OPTIMAL control plane for VPNs across public sections of the Internet is misguidance for these poor bellheads, and is leading them astray. What they really need is for the host security folks to wake up and completely obliterate the "value-added" VPN industry. | These people will cause you to lose hair Yeah, look at me! Sean.

1 0

Re: MPLS VPNs or not?
by Walter Prue 08 Aug '01

08 Aug '01

>Craig Partridge wrote: > >> the notion MPLS is faster to switch than IP reflects a poor >> knowledge of router innards, or a poor router design. David Charlap then wrote: >... >Over time, however, this advantage disappeared. IP best-match lookup >chips were developed that could do a proper IP lookup at full line rate >for OC-48 and even OC-192. With line-rate IP lookup, it's no longer >possible for something else to be faster. An aspect of MPLS routing that this may be overlooking is the fact that MPLS tunnels can be designed with certain attributes which implement a form of policy routing that normal least cost routing does not implement. That is, blue packets can route over this link but not red packets unless there is an outage of the S.F to N.Y. Link. Another policy might say that traffic from this customer may exit the backbone at only a few points. These engineered routing decisions are configured into an MPLS network so these routing decisions are not made on a packet by packet basis. Once data is stuffed into an MPLS tunnel that was set up with certain policies in mind you know that the data comes out at the other end. Intermediate nodes don't need to be convinced to "non-optimally" route this data but only this data. Walt

3 3

Re: MPLS VPNs or not?
by smd＠clock.org 08 Aug '01

08 Aug '01

| MPLS doesn't require per-hop policy decisions. Policy decisions only | need to be made at the edge OIC - so the decision to ACK or NAK a resource request when setting up an LSP is not subject to any policy control? I feel enlightened. Must be all the optical stuff enabled by this policy-free switched virtual circuit technology. | Parallels with the diffserv model of classifying & marking packets | at the edge so you only need to look at PHBs in the middle. Ah, Pointy Haired Bosses at the centre of things. Explains alot. | Instantiation of per-hop policy in MPLS consists of forwarding by LSP, | except at the edge router. Fortunately, creationist theory applies to the edge router's menu of labels to choose from, so nothing in the middle has to think at all (e.g. during setup, partition repair, ER/TE changes, etc.). Right? Sean. (anti-MPLS dinosaur)

1 0