- NANOG - lists.nanog.org

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

MPLS VPNs or not?
by Hank Nussbacher 08 Aug '01

08 Aug '01

Experts call MPLS bad for 'Net http://www.nwfusion.com/news/2001/0806mpls.html Intersting read. This should start a nice long thread :-) -Hank

16 46

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

08 Aug '01

avg: | > Yakov, that was not nice. | | Then to be consistent with your own position, you certainly should agree | that 2547 is "the way to do" VPNs, as with 2547 all the VPN-related | information is confined to the PEs (where "PE" stands for provider *edge*), | and none of the P (core) routers maintain any VPN-related information. Regrettably, even one's greatest allies on some fronts can develop tunnel vision. Sean. (not nice either)

1 0

Internet disruptions on multi-access networks, NAT and proxy caches
by Sean Donelan 08 Aug '01

08 Aug '01

Overall Internet performance measurements show only the typical variations in Internet performance. However, there have been several severe, but localized disruptions in multi-access networks, such as local ethernet, token ring and cable modem networks. There are also difficulties with some NAT devices and networks which aggressively use proxy web caches, such as international ISPs with small uplinks. This is a side-effect of Code Red II scanning the local subnet or network, and some network equipment having difficulty managing the ARP, NAT or proxy cache resource exhaustion. Due to the way IP forwarding works, point-to-point backbone router links are more or less immune to the problem. So I don't expect to see impact on the global Internet. But local enterprises and tier 2 through N ISPs could have problems with misbehaving servers on their networks.

1 0

Re: anybody seen this? (POST /PAV_REL HTTP/1.0)
by Matt Hite 07 Aug '01

07 Aug '01

Paul, This is a guess, but given a few clues in the header, I'd speculate that it's an anti-virus agent that utilizies Marimba technology for signature updates. (From what I understand, Marimba technology is incorporated into a number of applications for product updates, etc.) --Matt Hite On Tue, Aug 07, 2001 at 11:06:05AM -0700, Paul A Vixie wrote: > while hunting codered, i started seeing quite a few of the following: > > POST /PAV_REL HTTP/1.0 > User-Agent: TSTPAV > Connection: Keep-Alive > Content-length: 138 > Pragma: no-cache > Content-type: application/marimba > Request-type: update/12 > > what's being attempted here, and is anybody else seeing it? sometimes it's > > POST /PAV_REL HTTP/1.1 > Host: ... > Connection: keep-alive > User-Agent: TSTPAV > Content-length: 974 > Pragma: no-cache > Content-type: application/marimba > Request-type: update/12 > Via: 1.0 proxy-rnb (NetCache NetApp/5.1D3) > X-Forwarded-For: ... > > i'm not currently collecting the content, maybe i should. anybody seen this? > > ------------------------------

1 0