- NANOG - lists.nanog.org

Re: @Home ordered to shutdown at Midnight
by Sean Donelan 30 Nov '01

30 Nov '01

Dueling newswires Reuters story http://biz.yahoo.com/rb/011130/business_tech_exciteathome_dc_1.html Court Orders ExciteAtHome to Shut Service SAN FRANCISCO (Reuters) - A federal bankruptcy judge ordered Internet service provider ExciteAtHome Corp. (OTC BB:ATHMQ.OB - news) to shut its high-speed Internet service at midnight Friday, but said he was confident the company could quickly strike a new deal with cable companies to prevent service interruption for its some 4 million subscribers. Does Reuters know something CNet doesn't? On Fri, 30 Nov 2001, Christopher Schulte wrote: > From http://news.cnet.com/news/0-1004-200-8031722.html : > > "But Carlson said that "flipping the switch and shutting off service" was > highly unlikely." > > Do you know something they don't? > > At 04:18 PM 11/30/2001 -0500, you wrote: > > > >Judge Thomas Carlson ordered Excite@Home to shutdown as of > >Midnight Eastern time, tonight Friday November 30 2001. > > > >Bondholders are free to negotiate a better offer before > >the shutdown, if they can, to maintain the service. > >

2 1

NANOG 24 CFP
by Susan Harris 30 Nov '01

30 Nov '01

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS * * NANOG 24 * * February 10-12, 2002 * * * * * * * * * * * * * * * * * The North American Network Operators' Group (NANOG) will hold its 24th meeting February 10-12, 2002, in Miami, Florida. The meeting will be hosted by Terremark Worldwide. Registration begins January 2. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e., national/international) Internet backbone networking technologies and operational practices. Meetings are held three times each year, and include two days of short presentations, plus afternoon/evening tutorial sessions. The meetings are informal, with an emphasis on relevance to current backbone engineering practices. NANOG conferences draw over 600 participants, mainly consisting of engineering staff from national service providers, and members of the research and education community. <p> The meeting will be held at the Hotel Inter-Continental Miami. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Previous meetings have included presentations on: - Backbone traffic engineering - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - BGP case studies - Tools and techniques for ISP security - External route selection - IP multicast technologies ------------------------------------------------------------------------------ HOW TO PRESENT Submit a detailed abstract or outline describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is January 2, 2002. While the majority of speaking slots will be filled by January 2, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by January 16, 2002. NANOG also welcomes suggestions/recommendations for tutorials, panels and other presentation topics. ---------------------------------------------------------------------------

1 0

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