August 2001 - Test - lists.nanog.org

Re: MPLS VPNs or not?
by David Charlap 07 Aug '01

07 Aug '01

>> 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. > > Though I appreciate your point Dave,..... > > Throw enough silicon at any single problem and you can solve it. The > question is what can you do with the silicon you have at your > disposal for a given thermal/power/cost foot print. ... Don't misunderstand me. I am _NOT_ one of those people opposed to MPLS! I happen to be a developer working on MPLS software, and I think it is some very good technology. I was only referring to Craig's statement regarding some people's assertion that label/VC forwarding is faster than IP forwarding. I agree with him that this assertion is not true today, although it was true in the not-too-recent past. Other uses of MPLS (including traffic engineering, various kinds of VPN technologies, policies, etc.) are still very important, useful, and desirable features. -- David

1 0

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

07 Aug '01

> -----Original Message----- > From: Daniel Golding [mailto:dan@netrail.net] > > The scary thing is that the "speed" of MPLS-based networks is taken as > gospel by an alarming number of engineers, mainly those who > have come out of > the large telco's (i.e. ILECs), and are still kind of mad > that ATM didn't > work out. These folks are more or less alarmed by IP, and > desperately seek a > more deterministic, switch-based model of data transmission > for the Internet > as a whole. The fact that there is no practical, real-world > difference in > forwarding speed between straight IP, and IP over MPLS is generally > explained away by these guys in a fairly elaborate handwaving > exercise. At > least one major hardware vendor is not helping this, with > some of their > engineers convincing major customers that conventional IP > routing is bad, > and that anything MPLS is good. While I agree that MPLS has > it's uses - i.e. > TE as an exception handling mechanism for outages, and L2VPN > technology as a > FR/ATM replacement, some folks need to approach the technology with > additional caution, and not blindly embrace it as a panacea. > As the internet > engineering community evolves, learning from things like ATM, > becomes quite > important. > > - Daniel Golding I completely agree with this type of pragmatism. A couple of years ago, MPLS had only one viable application-TE for core IP networks. The implementations were buggy at first, but they have certainly improved. Nobody was *forced* to use it, but some service providers saw advantages to deploying it. Today, MPLS has more applications, such as routing optical lightpaths, L3 VPNs, L2 VPNs, and more applications will come. Again, nobody is *forced* to use any of them. Some of these applications may provide significant business advantage, some of them may crash the network. IMHO, it is a Good Thing(TM) that vendors are coming up with these new applications, because it gives service providers multiple choices in terms of the types of service they could offer, assuming they were willing to take the risk in deploying these services. If you don't NEED protocol X, where X=[RFC 2547, QoS, L2VPNs, GMPLS, pick your favorite proposal here], don't use it. If you don't LIKE protocol X it, don't use it, and hope that: A.) Your competitors deploy it, and B.) Your hunch was right and you make more money than your competitors as the result of your decision. Ultimately, we should let the market decide. Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi(a)tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720

1 0

RE: MPLS VPNs or not?
by Irwin Lazar 07 Aug '01

07 Aug '01

>> 1984 OSI >Usable parts adapted for IP use. I think we can all agree that IS-IS is still a fairly viable technology?

1 0

anybody seen this? (POST /PAV_REL HTTP/1.0)
by Paul A Vixie 07 Aug '01

07 Aug '01

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?

2 1

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

07 Aug '01

> -----Original Message----- > From: Irwin Lazar [mailto:ILazar@tbg.com] > > I also found it interesting that the critics of MPLS as "bad > for the 'net" > work for a company that currently offers MPLS-based VPN > services in the U.S. > (IP Enabled Frame Relay) and is rolling those services out to > Europe while > also expanding them to support ATM speeds. I'm betting that > there are quite > a few very upset product managers at AT&T this morning. > > Irwin I thought this was interesting as well. This other group within AT&T has obviously looked at the potential scaling problems, the risks associated with it, and continue to deploy it. As a side note, this group has built large networks in the past, and given the size and scope of their networks, have a stability that most operators would envy. Oh by the way, they are profitable too. Randy, what was your point again? Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi(a)tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720

2 1

Blocking Code Red and other HTTP Hacks using NBAR
by Scott Frisby 07 Aug '01

07 Aug '01

This solution will be posted on CCO in the next day or so and will be referenced in the Cisco's Security Advisory as well. http://iponeverything.net/CodeRed.html You comments and thoughts are welcome - My thought is that this solution would really be useful on managed customer prem routers to block both inbound and more effectively outbound sessions to prevent code red infection. Please feel free to forward to customers. I will follow up with the official CCO release. Also policing and droping on conformance will work as well. Regards, Scott E. Frisby CCIE # 5059 Product Manager - NBAR Enterprise Solutions Engineering C i s c o S y s t e m s Voice: (408) 853-7018 Pager: 1-800-365-4578 Pager: 1-800-796-7363 p1032646 e-mail: sfrisby(a)cisco.com e-page: sfrisby(a)epage.cisco.com

1 0

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

07 Aug '01

On 8/7/2001 at 17:33:39 +0100, Randy Bush said: > > > That would be a rational position, but it can't be accepted by the > > folks who have a fairly irrational attitude about the subject. > > love those ad hominem arguments by the desperate in the defense of clearly > non-scalable technology. will ad homina be part of 2547bis? The sad thing here is, you repeated what the complaints are about in your reply: specifically, you keep telling us it is "clearly non-scalable," but you also fail to tell us why. So: 1) 2547bis requires configuration at the ends only, just like any other IP service in a properly configured network. 2) The routing descriptor space is larger than the IP space, so it does not present a limiting factor. 3) The BGP mesh requirements are the same as for any other BGP-aware network (barring implementation issues, which are not a problem with the protocol itself.) The additional configuration can be as static or as dynamic as any other IP service. 4) The memory requirements for the additional routes are the same as for any other IP routes, plus a little overhead for tracking the routing table. This additional overhead does not appear to be significant. Therefore, I would say that 2547bis is clearly scalable, or at least, as scalable as internet IP service. -Dave

1 0

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

07 Aug '01

On 8/7/2001 at 15:14:02 +0100, Randy Bush said: > > > Take a look at the mpls(a)uu.net archives for a rather exhaustive and > > exhausting discussion of this very subject, or provide facts as to what > > specifically doesn't scale. > > to paraphrase vijay, if dealing with one rib is a major discussion in the > operator and ietf communities, how many thousands of them do you think a > prudent operator wants to deal with in 2547? And on some agricultural list somewhere, they're discussing the proper way to raise a sheep. If there's all that discussion about how to raise one sheep, who wants to deal with a flock? Once you know how to deal with one big table, dealing with a bunch of tiny, simple tables is pretty easy, especially since, once you build them, they mainly take care of themselves. This really isn't that much to it, folks. If you're very brave and very careful, you can let your customers handle their routes. Otherwise, you can statically route to them. If you don't want to handle all those routes in your VPN networks, how many more plain IP customers are you going to handle? Configuring routing for an RFC 2547 MPLS VPN is not really much harder than configuring a plain IP customer. It can certainly be automated just as easily. Perhaps the issue here is, the folks arguing against the complexity are targeting their arguments on the people who really don't need to worry about it: the small network operators, who have a small support staff trying to run a BGP-enabled network. These guys might be MPLS VPN customers, but there's no need for them to be providers. To leech another person's metaphor here, the argument is that a 747 is too hard for your average pilot to fly. Fortunately, your average pilot doesn't have to fly it. -Dave

1 0

Re: MPLS VPNs or not?
by Robert Raszuk 07 Aug '01

07 Aug '01

Randy, For me you can complain to vedors that they make crappy boxes which don't do what you need. That is fine and I will not say a one bad word against it. On the other hand I (helping to deploy mpls-vpns around the world for a few years in a number of networks including these days even your ATT) just can't watch stating that the arcitecture of 2547 is screwed only because current platforms don't scale 5 years ahead. R. > Randy Bush wrote: > > > 5 years from now you will see routers from multiple vedors allowing you > > to store & process orders of mangnitute of more routes. > > good, because i will need them for the normal default-free zone. > > but today, the vendors seem to think i need massively more routers to > support this grotty hack. and i suspect that you'll be telling me i > still need that whoileparallel network five years from now. > > randy

1 0

fire on MIT campus affecting LCS and W3C
by Nick Feamster 07 Aug '01

07 Aug '01

fyi ---------- Forwarded message ---------- Date: Tue, 7 Aug 2001 10:39:33 -0400 (EDT) Subject: fire on MIT campus affecting LCS and W3C Apparently there was a fire on the MIT campus that is affecting access to LCS and W3C web servers. The fire got a major power line.

1 0