- Test - lists.nanog.org

RE: MPLS in metro access networks
by Quibell, Marc 30 Nov '01

30 Nov '01

I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)" As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned. Your last statement indicates "added services" have nothing to do with the the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc: "This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services." Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog(a)merit.edu Subject: RE: MPLS in metro access networks I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in the original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS that are the major benefit. -Michael Cohen -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen(a)thrupoint.net'; 'nanog(a)merit.edu' Subject: RE: MPLS in metro access networks soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":) Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks I hope so:) -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen(a)thrupoint.net'; nanog(a)merit.edu Subject: RE: MPLS in metro access networks Are we talking about Multiprotocol Label Switching? Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog(a)merit.edu Subject: RE: MPLS in metro access networks And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas. Cheers, -Michael Cohen -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog(a)merit.edu Subject: RE: MPLS in metro access networks I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS.... Marc -----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog(a)merit.edu Subject: MPLS in metro access networks Hello: I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks. To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it). Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated. Regards, Srihari Varada

7 9

Re: a question about the economics of peering
by Bill Woodcock 30 Nov '01

30 Nov '01

Alex Rubenstein wrote: > Today, I was approached by *unnamed-ethernet-extension-company*. I take it this was PacketExchange? There are several other companies in, or entering, that market right now as well. Most of them haven't a clue about the economics of the field they're in, and will go down in flames as quickly as they can burn their first-round funding. > My belief is that generally speaking, networks meet at public > exchange points to exchange traffic with each other more > economically. Yes, you're correct. Specifically, one participates at exchanges that offer sufficiently attractive routes such that one's per-bit delivery cost is, on average, lowered as a consequence of participating at the exchange. That is, the total cost of participation in the exchange must be less than the cost of delivering the same number of bits via transit. That's why many of the most successful exchanges are also often the cheapest, with the fewest services... They exceed that price/performance threshold more easily than exchanges that feature expensive services. Um, that's something of a tautology, sorry, but I think you get my point. > His belief is that people will pay a premium to get to an exchange > point I hope he believes in Santa Claus too, else his company is going to encounter a rude shock when it tries to make a sale. > Essentially, he said that paying more for peering that for transit is > typical, and to be expected, and most people accept this. Nope. He's as wrong as can be. -Bill

1 0

Re: a question about the economics of peering
by brandon＠rd.bbc.co.uk 30 Nov '01

30 Nov '01

> BTW, public IXen in Europe don't tend to be congested. Whether this is > the result of better management, or of lower traffic volumes Possibly, they also tend to be member owned so people have a stake in making them work whereas a commercial IX may have other priorities We have virtually zero visibility into what's going on inside commercial IX compared to the data we see in member organisations - it's hard to hide stuff from the members Doesn't mean commercial is bad though brandon

1 0

Customers are demanding diversity a lot more
by Sean Donelan 30 Nov '01

30 Nov '01

Verizon spokesmen are quoted in the Wall Street Journal that nearly all voice and data service has been restored since September 11 attacks. Although the article also points out some customers are relying on CLEC services because Verizon hasn't restored their service. According to Verizon, about 8000 circuits are still nonfunctional. Verizon estimates it will spend about $1 billion on its recovery efforts. AT&T has released a video showing its employees response since September 11. According to an AT&T spokesmen, AT&T spent about $300 million to maintain its ability to recover a complete switching site. Genuity has rehomed the customers previously connected to its WTC pop. And now (only now?) has plans to connect its data centers through diverse POPs. It is also adding the ability to identify specific types of customers, such as government, hospitals, etc in case it needs to provide them service in an emergency. The voice network has had a "service restoration priority" program for a long time, until now ISP services were not covered by such a concept. Worldcom and Sprint are maintaining their "no comment" policy.

1 0

ACLs / Filter Lists - Best Practices
by John McBrayne 30 Nov '01

30 Nov '01

Is anyone aware of any current "best practices" related to the recommended set of filtering rules (Cisco ACL lists or Juniper filter sets) for reasons of Security, statistics collection, DoS attack analysis/prevention, etc.? I'm curious to see if there are any such recommendations for Tier 1/Tier 2 backbone routers, peering points, etc., as opposed to CPE terminations or Enterprise/LAN equipment recommendations. Actual config file examples would be great, if they exist. Thanks; ..john

11 11

Exodus assimilated by C&W
by Dan Hollis 30 Nov '01

30 Nov '01

After assimilating more than they could handle, exodus gets assimilated themselves... http://biz.yahoo.com/prnews/011130/sff021_1.html -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

1 0

Re: bgp geopolitical analysis (warning: zero operational content. or so.)
by Hank Nussbacher 30 Nov '01

30 Nov '01

On Thu, 29 Nov 2001, David Williamson wrote: > On Thu, Nov 29, 2001 at 09:33:05AM +0200, Hank Nussbacher wrote: > > ZA has the 3rd highest prefix count at 2700.Why does South Africa have > > such a high prefix count? > > I thought it might be interesting to look at the ratio of prefixes > to ASes.While some ASes may have a large number of ip allocations, > and hence a need for more prefixes to be announced, most have rather few > prefixes that need to be announced.On the other hand, as we all know, > many ASes announce far more prefixes than necessary.Here's the top few > in the list when sorted by ratio of prefixes to ASes: > > country prefixes/ASes > ZA 77.22857143 Something in ZA looks skewed. Can anyone shed light as to why ZA has so many small prefixes (even with lots of users)? Lack of CIDR? Poor allocation methods? Clueless ISPs? Thanks, Hank > PK 38.75 > IN 30.83333333 > AU 27.6713615 > CL 24.25 > FI 22.68181818 > CA 22.23012552 > PR 21.66666667 > EC 21.66666667 > NZ 21.16129032 > > I've removed countries with fewer than 100 prefixes, since they have > nearly meaningless ratios.The US is in the 11 range, and ?? comes in > down around 9. > > -David > Hank Nussbacher

1 0

OT: Secret email?!
by Joe Blanchard 30 Nov '01

30 Nov '01

Greetings all I know this might have been brought up before so please disregard if so. Thought it might be of interest to some. While looking for ways to indicate that nimda/codered ect was pushed to a client within my network, I tripped across something completely unrelated, but interesting. It seems these email clients that utilize html formating also send out information unknowingly. I know nothing new, but heres the senario. A spam email arrives, client opens/previews the email and its pretty gifs/jpgs ect, while at the bottom a link is retrieving what looks like a logo. Example: <a href="http://www.em5000.com"><img src="http://www.em5000.com/counter.php?client=newhorizons&email=myemail@addy .com&msgid=281101000" width="109" height="16" border="0" alt="em5000.com"></a> What it does in fact is send information to a host (from the firewall's view): > 12:54:01: %PIX-5-304001: 10.1.1.10 Accessed URL > 66.77.58.92:/counter.php?client=newhorizons&email=myemail@domain.com&msgid > =281101000 > (from the host's view): GET /counter.php?client=newhorizons&email=myemail(a)domain.com&msgid=281101000 HTTP/1.1 which in turn (I suppose) places my email address into a database thats used for spaming. i.e. verifying that my email address is valid. While watching for this behavior, I saw about 10 other nodes/users do this, none of which knew the information had been sent out. Kind of sneaky if you ask me. Cheers -Joe

2 1

Re: OT: Secret email?!
by Steven M. Bellovin 30 Nov '01

30 Nov '01

In message <E9BBE0941932D511934C0002A52CDB4E0127F6B2(a)sj-exchange.wyse.com>, Joe Blanchard writes: > >Greetings all > >I know this might have been brought up before so please disregard if > so. Thought it might be of interest to some. > > While looking for ways to indicate that nimda/codered ect was >pushed to a client within my network, I tripped across something >completely unrelated, but interesting. > >It seems these email clients that utilize html formating also >send out information unknowingly. I know nothing new, but heres >the senario. A spam email arrives, client opens/previews the email >and its pretty gifs/jpgs ect, while at the bottom a link is retrieving >what looks like a logo. Example: > ><a href="http://www.em5000.com"><img >src="http://www.em5000.com/counter.php?client=newhorizons&email=myemail@addy >.com&msgid=281101000" width="109" height="16" border="0" >alt="em5000.com"></a> > >What it does in fact is send information to a host >(from the firewall's view): >> 12:54:01: %PIX-5-304001: 10.1.1.10 Accessed URL >> 66.77.58.92:/counter.php?client=newhorizons&email=myemail@domain.com&msgid >> =281101000 >> >(from the host's view): >GET /counter.php?client=newhorizons&email=myemail(a)domain.com&msgid=281101000 >HTTP/1.1 > >which in turn (I suppose) places my email address into a database thats used > >for spaming. i.e. verifying that my email address is valid. While watching >for this behavior, I saw about 10 other nodes/users do this, none of which >knew the information had been sent out. Kind of sneaky if you ask me. Yup -- that's why I turn off images on those rare occasions that I bother to read html email. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

RE: Followup British Telecom outage reason
by Youse, Chuck 30 Nov '01

30 Nov '01

You'll forgive me for being cynical here, but I seriously doubt that any Linux-derived operating systems could truly qualify as 'real-time'. To meet the requirements for an RTOS, Linux would have to be so heavily mutated that it would no longer be Linux. Cheers Chuck -----Original Message----- From: Patrick Greenwell To: Christian Kuhtz Cc: Alex Bligh; Paul Vixie; nanog(a)merit.edu Sent: 29/11/01 07:49 Subject: RE: Followup British Telecom outage reason On Wed, 28 Nov 2001, Christian Kuhtz wrote: > > > I guess some time someone will realize routers are both > > hardware, and software, and shock horror both, if done > > well, can actually add value. [hint & example: compare the > > scheduler on, say, Linux/FreeBSD, Windows 95 (sic), > > and your favourite router OS (*); pay particular attention > > to suitability for running realtime, or near realtime tasks, > > where such tasks may occasionally crash or overrun their > > expected timeslice; note how the best OS amongst the > > bunch for this aint exactly great]. > > > > (*) results may vary according to personal choice here. > > Don't use a non-realtime OS for something that you expect realtime or > near-realtime OS functionality. There are specific systems to address these > kinds of needs with rather complicated scheduling mechanism to accomodate > such requirements in a sensible manner. > > Is IOS a realtime operating system? No. Are any of the other listed OS > realtime operating systems? No. Actually there are multiple Linux-based RTOSes.

3 2