Re: Interconnects
On Fri, 17 May 2002, Sean Donelan wrote: On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: perhaps better late than never... PAIX LINX both have IPv6 capabilities at/on the exchange fabric(s). I am not aware that Equinix has taken that step. Uhm, another dumb question. Why does the operator of a layer 2 exchange care (or know) what protocols your are using? IPv4, IPv6, heck I remember seeing Appletalk, OSI and DECNET on MAE-EAST. What consenting network operators do LINX for example permits very specifically IPv4 only, no multicast including routing protocols etc, no mac broadcasts ie spantree. I think theres a danger on very large switching fabrics that if youre not specific things will happen that are detrimental to all members.. all major switching problems I know of at LINX were caused by members doing something not permitted by the rules... Just because you -could- do something without the operator knowing doesnt mean you should, the rules are there for everyones protection and I think the fact that when people do things they shouldnt it has caused problems speaks for itself in that respect. Steve What step does Equinix (or any other layer 2 exchange) need to do? The ATM NAPs might have an issue due to ATM/ARP, but even then I suspect two consenting network operators could use static IPv6 ARP tables without the NAP operator doing anything.
Re: Multicast at broadcast exchanges
On Fri, 17 May 2002 17:25:10 -0700 Toerless Eckert [EMAIL PROTECTED] wrote: Hi Toerless; We had this discussion some time back on a different mailing list (mboned ?.. not sure). I don't remember who was actually trying to collect different options here, but in general, either all participants Bill Nickless at such a MIX agree who is the best upstream router for some multicast traffic - then it's just the question how technically to guarantee the route consistency - or they don't, and in this case you need to use one VLAN per upstream participant, do appropriate filtering on them so really only the VLANs owner can sent multicast into it and the downstreams can only receive, and set up appropriate peerings. Today, MIXes are all AFAIK all single VLAN for multicast which means that there must be a coordinated BGP configuration policy between the upstream participants to ensure that the way PIM asserts resolve does actually elect the one upstream that is best. Of course, the policy that can be expressed is limited by the fact that PIM asserts are used to resolve conflicts. Foundry has a limited PIM snooping ability on their switches. Does anyone know of an operational PIM-Snooping based MIX ? Regards Marshall Eubanks Cheers Toerless P.S.: Oh, and of course one way to get a multi-policy setup very simply without multiple VLANs is by not using ethernet but instead an ATM with rfc2225/rfc2337 (eg: one classical-ip subnet with PIM Multipoint signalling). P.S.2: Oh and by the way: The DR function is completely irrelevant in this discussion because it only applies to IGMP state driven forwarding, and you shouldn't really use that on a router connecting to a MIX. If you do, you're even more constrained in your options and probably need to go to a multi-vlan setup immediately. On Fri, May 17, 2002 at 06:00:41PM -0400, Stephen Griffin wrote: Hmm, I was thinking about the topic of multicast at broadcast exchanges, and had a weird thought. Presently, the various participants may have divergent peering relationships and routing preferences. Such that RPF choices for the same (s,g) can go back to different places. If I remember correctly, all PIM routers on the same broadcast domain will elect a designated router, to keep from sending the same traffic for the same group multiple times. If network A is preferring network B (via localpref, for example) and network C is preferring network D, such that A rpf's to B for prefix E and C rpf's to D for prefix E, how would this be resolved? What if A doesn't peer with D at all, and C doesn't peer with B? Wouldn't one of B and D send the traffic, such that the other isn't sending any, regardless of the policies of any of the networks involved? What if the elected DR isn't one of B or D? The only workaround I could see, would be if the multicast traffic were unicasted across the exchange (much like how things are at the atm peering points). However, this nulls out the benefit of having a multicast broadcast exchange.
Re: Interconnects
On Sat, 18 May 2002 11:14:47 +0100 (BST) Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Fri, 17 May 2002, Sean Donelan wrote: On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: perhaps better late than never... PAIX LINX both have IPv6 capabilities at/on the exchange fabric(s). I am not aware that Equinix has taken that step. Uhm, another dumb question. Why does the operator of a layer 2 exchange care (or know) what protocols your are using? IPv4, IPv6, heck I remember seeing Appletalk, OSI and DECNET on MAE-EAST. What consenting network operators do LINX for example permits very specifically IPv4 only, no multicast including routing protocols etc, no mac broadcasts ie spantree. Doesn't the LINX have a separate LAN for a multicast exchange ? I know that this was set up, but I don't know what it's current status is. Regards Marshall Eubanks I think theres a danger on very large switching fabrics that if youre not specific things will happen that are detrimental to all members.. all major switching problems I know of at LINX were caused by members doing something not permitted by the rules... Just because you -could- do something without the operator knowing doesnt mean you should, the rules are there for everyones protection and I think the fact that when people do things they shouldnt it has caused problems speaks for itself in that respect. Steve What step does Equinix (or any other layer 2 exchange) need to do? The ATM NAPs might have an issue due to ATM/ARP, but even then I suspect two consenting network operators could use static IPv6 ARP tables without the NAP operator doing anything.
Re: PAIX (was Re: Interconnects)
On 17 May 2002, Paul Vixie wrote: I welcome any further questions about PAIX's health or future. When we Why no optional MLPA like AADS? Even though AADS is overpriced, I considered it just because of the long list of companies that are signed up on the MLPA. -Ralph
Re: PAIX (was Re: Interconnects)
I welcome any further questions about PAIX's health or future. [...] Why no optional MLPA like AADS? [...] we had one at first. after a few years of approximately no signatories, we stopped trying. my own experience is that bilaterals are more useful for engineering purposes and that multilaterals are kind of swampy. but if there's interest, we'll find the old paperwork and shuffle it anew. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNXE)
Re: PAIX (was Re: Interconnects)
Why no optional MLPA like AADS? [...] we had one at first. after a few years of approximately no signatories, we stopped trying. my own experience is that bilaterals are more useful for engineering purposes and that multilaterals are kind of swampy. One BGP session instead of dozens is more convenient. Maybe not more useful for engineering, but certainly less work than negotiating and configuring a bunch of sessions for bilateral peering. For smaller ISPs like mine, knowing in advance that you won't get snubbed for peering after connecting to an exchange is the big attraction. Given the dozens of signatories on the AADS MLPA, it looks like they can be quite popular. -Ralph
route statistics
I'm trying to collect statistics on how many routes match certain patterns. So far I've been using zebra, set term len 0, and then sh ip bgp regexp, and wait for the total prefixes count at the end of the list. I figure there must be a better way than this, but so far haven't found one. Any ideas? Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
Re: portscans (was Re: Arbor Networks DoS defense product)
On Sat, May 18, 2002 at 05:25:27PM -0400, [EMAIL PROTECTED] said: [ On Saturday, May 18, 2002 at 13:48:27 (-0700), Scott Francis wrote: ] Subject: Re: portscans (was Re: Arbor Networks DoS defense product) However a portscan is not an attack. Precursor to an attack, certainly. B.S. A plain old port or IP scan is nothing more than an information gathering excercise. Unless you're the one running it you almost certainly have no clue whatsoever why it was started. (Unless you can prove somehow that the scan pattern and/or packets matches a signature that's proven to be _unique_ to some known attack tool.) And why, pray tell, would some unknown and unaffiliated person be scanning my network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks). -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui msg01907/pgp0.pgp Description: PGP signature
Re: Network Reliability Engineering
Good luck. For a proper scientific analysis you'd need MTBF info on every point of failure - i.e. the physical link, CSU/DSU, power supply, ... As a rather non-scientific observation, a couple outages per year of 1-4 hours seems to be quite common for a single-homed T1 or faster connection, be it from WorldCom, ATT, Sprint... I think the arguments in favor of dual-homing are pretty cut and dry. Tri-homing vs dual-homing would be a much tougher benefit to quantify. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Sat, 18 May 2002, Pete Kruckenberg wrote: I'm looking for some good reference materials to do some reliability engineering calculations and projections. This is to justify increased redundancy, and I want to include quantifiable numbers based on MTBF data and other reliability factors, kind of a scientific justification instead of just the typical emotional appeal using analyst/vendor FUD. I'd appreciate references on how to do this in a network environment (what data to collect, how to collect it, how to analyze, etc). Also any data (or rules of thumb) on typical MTBFs for network events that I won't find on vendor product slicks (like what's the MTBF on IOS, or human-caused service outages of various types, etc). If someone has put together something remotely like this that they'd care to share, that'd be incredibly helpful. Thanks. Pete.
Re: Interconnects
On Sat, 18 May 2002, Marshall Eubanks wrote: On Sat, 18 May 2002 11:14:47 +0100 (BST) Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Fri, 17 May 2002, Sean Donelan wrote: On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: perhaps better late than never... PAIX LINX both have IPv6 capabilities at/on the exchange fabric(s). I am not aware that Equinix has taken that step. Uhm, another dumb question. Why does the operator of a layer 2 exchange care (or know) what protocols your are using? IPv4, IPv6, heck I remember seeing Appletalk, OSI and DECNET on MAE-EAST. What consenting network operators do LINX for example permits very specifically IPv4 only, no multicast including routing protocols etc, no mac broadcasts ie spantree. Doesn't the LINX have a separate LAN for a multicast exchange ? I know that this was set up, but I don't know what it's current status is. Yep, its a completely separate LAN operated by LINX.. theres a number of members using it. Actually, I'm not one of them.. I was thinking about this today and wondered if people think they are benefiting at all from using multicast exchange points or even just receiving multicast over say a tunnel. I know the benefits of the technology but in reality, today, is anyone using multicast as an ISP and getting something out of it over unicast? Steve Regards Marshall Eubanks I think theres a danger on very large switching fabrics that if youre not specific things will happen that are detrimental to all members.. all major switching problems I know of at LINX were caused by members doing something not permitted by the rules... Just because you -could- do something without the operator knowing doesnt mean you should, the rules are there for everyones protection and I think the fact that when people do things they shouldnt it has caused problems speaks for itself in that respect. Steve What step does Equinix (or any other layer 2 exchange) need to do? The ATM NAPs might have an issue due to ATM/ARP, but even then I suspect two consenting network operators could use static IPv6 ARP tables without the NAP operator doing anything.
EBITDA [was Re: Interconnects]
On Sat, 18 May 2002, Mike Leber wrote: press releases regarding their other choices, or perhaps considering whether the companies they consider alternatives are EBITDA postive (making a profit, or in otherwords will exist in 12 months) today (not in an imaginary planned future) or for the few that are EBITDA positive, whether they actually seem to want your business. EBITDA positive does not mean profitable, or even necessarily financially stable. EBITDA is earnings before interest, taxes, depreciation, and amoritization -- all things that tend to have an impact on your finances. If you were using EBITDA as the measure of your personal financial situation, you could spend far more than your after tax income, but less than your before tax income, and declare yourself to have come out ahead. Your bank, however, probably wouldn't see it that way. The same goes for corporate finance, except that the corporations that were announcing their EBITDA numbers as the important financial data often had enough in the bank, and enough market cap, that it didn't become a critical problem for a few years. My understanding is that EBITDA does have legitimate accounting uses, but I'm not clear on what they are. I'm tempted to label this message as off-topic nitpicking, but given that the biggest problem with Internet stability at the moment seems to be financial, I'm not sure it is. -Steve Steve Gibbard [EMAIL PROTECTED]
Re: Corporate PGP for network operators
On Fri, 17 May 2002, Sean Donelan wrote: Ok, extremely dumb question. But I'm sure lots of other people have already solved this one. Ask a dumb question, get 37 dumb answers. Summary One recommendation for the GnuPG plug-in for Outlook One inquiry how many licenses I was interested in buying The rest, mostly recommendations about alternative operating environments.
Fwd: RE: Network Reliability Engineering
AHH, MTBF date from vendorswell, there goes the idea of THAT project. You'll find that data, IF you can find it, will be calculated by sales cretins, not engineers. Check out this book: High-Availability Network Fundamentals Cisco Press ISBN 1-58713-017-3 Despite its Cisco Press origin, the book is 99% vendor-neutral and applies to any equipment. It helps you calculate MTBF-based availability of entire network paths, factoring in various types of redundancy. You're on your own collecting actual MTBF data from vendors, but this book may help you put it together into something sensible.
Re: EBITDA [was Re: Interconnects]
On Sat, 18 May 2002, Steve Gibbard wrote: EBITDA positive does not mean profitable, or even necessarily financially stable. EBITDA is earnings before interest, taxes, depreciation, and amoritization Correct, however I was trying to provide a simplified translation. A company that isn't EBITDA positive can't survive by declaring bankruptcy becausee even after they get rid of the interest payments they will still have a negative run rate. The reason for using EBITDA as an early indicator for financial health when analyzing companies is that it allows you to look at the health of the operation independent of their debt structure and prior capital expenditures (depreciation and amortization) so that you can get a better idea of their cash flow. The reason why cash flow matters is because when a company runs out of cash bankruptcy is imminent. Profitiability from a PL statement (expecially for public companies) involves so many components that it frequently doesn't allow you to evaluate a company until it has matured. The same goes for corporate finance, except that the corporations that were announcing their EBITDA numbers as the important financial data often had enough in the bank, and enough market cap, that it didn't become a critical problem for a few years. True, however by looking at EBITDA and current assets (cash in the bank) you can get a quick picture of the likely hood a company solving anything by declaring bankruptcy and a rough time frame to their imminent demise. My understanding is that EBITDA does have legitimate accounting uses, but I'm not clear on what they are. I hope you find my explanation above a useful rule of thumb. I'm tempted to label this message as off-topic nitpicking, but given that the biggest problem with Internet stability at the moment seems to be financial, I'm not sure it is. Due to the fact that I've had to order redundant capacity from multiple vendors in situations where there was enough traditional physical network redundancy, this seems to have become an important network provisioning issue. Mike. +--- H U R R I C A N E - E L E C T R I C ---+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: Re[2]: portscans (was Re: Arbor Networks DoS defense product)
AL Date: Sat, 18 May 2002 21:50:34 -0400 AL From: Allan Liska AL [allan@ns1 phpdig]$ telnet www.istop.com 80 AL Trying 216.187.106.194... AL Connected to dci.doncaster.on.ca (216.187.106.194). AL Escape character is '^]'. AL HEAD / HTTP/1.0 Or lynx http://www.istop.com/ and press the '=' key for similar info. Or echo the HEAD request to a program that opens a TCP socket. Or go to www.netcraft.com. Of course, firewalls munching on TCP/IP can screw up IP stack fingerprinting, causing nmap et al. to report IIS on favorite *ix flavor when it really means IIS on ??? behind firewall running favorite *ix flavor. I wonder how many people enjoy recompiling their *ix httpd to report itself as IIS? Watch for requests matching certain IDS strings... what was that again about mad fast honeypots? ;-) -- Eddy Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: PAIX (was Re: Interconnects)
On Sat, May 18, 2002 at 04:51:27PM -0400, Ralph Doncaster wrote: One BGP session instead of dozens is more convenient. Maybe not more useful for engineering, but certainly less work than negotiating and configuring a bunch of sessions for bilateral peering. For smaller ISPs like mine, knowing in advance that you won't get snubbed for peering after connecting to an exchange is the big attraction. Given the dozens of signatories on the AADS MLPA, it looks like they can be quite popular. Strictly speaking, I don't think a route-server is required to multilaterally peer, but they certainly help. However, there are a couple of big catches, particularly on an ATM or similar switching fabric: 1) One or two sessions, one or two VCs...if they go down, you will lose all your peering at that site. 2) The possibility of blackholing traffic to a peer who you have a downed VC to, but who is still advertising their prefixes to the route server. Additionally, quality of peering does not necessarily correlate to quantity of peering. I'm not going to claim that it's a bad thing to peer with a large number of typically smaller providers, but they don't always account for a statistically signifigant portion of your traffic. If you're going to have to negotiate bilateral agreements to cover the bulk of your peering traffic, why not consistantly negotiate bilateral agreements? --msa
Re: portscans (was Re: Arbor Networks DoS defense product)
[ On Saturday, May 18, 2002 at 16:03:11 (-0700), Scott Francis wrote: ] Subject: Re: portscans (was Re: Arbor Networks DoS defense product) And why, pray tell, would some unknown and unaffiliated person be scanning my network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks). I scan networks and hosts very regularly for legitimate diagnostic purposes as well as occasionally for curiosity's sake. I've never attacked any host or network that I was not directly responsible for. If you don't want the public portions of your network mapped then you should withdraw them from public view. BTW, please be one heck of a lot more careful with your replies. My original reply to you was not copied to the list and I did not give you permission to post a response quoting my words back to the list. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: portscans (was Re: Arbor Networks DoS defense product)
On Sat, May 18, 2002 at 07:17:43PM -0400, [EMAIL PROTECTED] said: [snip] network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks). I often like to know if a particular web server is running Unix or Winblows. A port scanner is a useful tool in making that determination. a full-blown portscan is not required here. A simple telnet to port 80 will do the job. sarcasm And why, pray tell, would some stranger be carrying a concealed gun if they were not planning on shooting someone? /sarcasm Show me how to defend myself from attack by portscanning the networks of random strangers, and I will concede the point. :) -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui msg01924/pgp0.pgp Description: PGP signature
Re: portscans (was Re: Arbor Networks DoS defense product)
On Sat, May 18, 2002 at 09:43:16PM -0400, [EMAIL PROTECTED] said: [snip] network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks). Before choosing an onling bank, I portscanned the networks of the banks I was considering. It was the only way I could find to get a rough assessment of their network security, which was important to me as a customer for obvious reasons. In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To make it a bit more clear: cases where the scanner can demonstrate a good and benign reason for scanning (they do occasionally exist[1]), no blackhole is required. Sending an email notification prior to putting in a blackhole is a good first step to eliminate potential false positives. [1] Random strangers unaffiliated with your network will almost never have a valid benign reason for portscanning you. I'm not sure if I would have been impressed or annoyed if they had stopped accepting packets from my machine during the scan. :-) Loss of a customer, probably. :) -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui msg01925/pgp0.pgp Description: PGP signature
Re: portscans (was Re: Arbor Networks DoS defense product)
On Sat, May 18, 2002 at 11:05:34PM -0400, [EMAIL PROTECTED] said: [ On Saturday, May 18, 2002 at 16:03:11 (-0700), Scott Francis wrote: ] Subject: Re: portscans (was Re: Arbor Networks DoS defense product) And why, pray tell, would some unknown and unaffiliated person be scanning my network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks). I scan networks and hosts very regularly for legitimate diagnostic purposes as well as occasionally for curiosity's sake. I've never Legitimate diagnostic purposes would mean that you would not fall into the category of unknown and unaffiliated. Curiosity's sake, well ... depends on whose network it is. attacked any host or network that I was not directly responsible for. If you don't want the public portions of your network mapped then you should withdraw them from public view. Agreed there. Defense is important. It might be good to note that I'm not giving a blanket condemnation of all portscans at all times; but as a GENERAL RULE, portscans from strangers, especially methodical ones that map out a network, are a precursor to some more unsavory activity. BTW, please be one heck of a lot more careful with your replies. My original reply to you was not copied to the list and I did not give you permission to post a response quoting my words back to the list. Apologies; my finger was a bit too quick on the 'g'. As this message came to the list, I will assume it is safe to cc the list on my reply. Sorry about that last. -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui msg01926/pgp0.pgp Description: PGP signature
Re: portscans (was Re: Arbor Networks DoS defense product)
[ On Saturday, May 18, 2002 at 20:15:10 (-0700), Scott Francis wrote: ] Subject: Re: portscans (was Re: Arbor Networks DoS defense product) Apologies; my finger was a bit too quick on the 'g'. As this message came to the list, I will assume it is safe to cc the list on my reply. Sorry about that last. Apology accepted, but I strongly recommend you learn to use some more reliable mail reader software -- something that doesn't accidentally invent reply addresses! There was no hint that my message to you was in any way associated with the NANOG list -- it was delivered directly to you and CC'd only to the person you were responding to. Some outside influence had to have associated it with having been a reply to a list posting and connected your desire to reply with inclusion of the list submission address. According to your reply's headers you're using Mutt-1.3.25i, and according to the Mutt manual 'g' is the group-reply command. I don't find any hint in the description of that command to indicate that it will magically associate a given message with a list, especially one that was not received from the list. Even the 'list-reply' command should not be able to associate a private reply with the list address. If Mutt really does magically associate private replies with list addresses by some mysterious mechanism then it's even more broken than I suspected. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: EBITDA [was Re: Interconnects]
EBITDA positive does not mean profitable, or even necessarily financially stable. Right you are. So please let me clarify my earlier statement (that PAIX has been modestly profitable for years). If we were not a wholly owned subsidiary we would owe income taxes. When we have been wholly owned by companies who were paying income taxes, some of the taxes they had to pay were because of PAIX. (Presumably this positive our income situation will make it easy for MFN to sell us.) Let's have a look at Extreme Networks' recently published financials. (Bring up http://biz.yahoo.com/fin/l/e/extr.html to follow along.) These folks showed a net loss this quarter yet the analysts applauded them and their stock shot up a bit because they had a nonrecurring charge larger than their net loss. This tells analysts that the company would have taxable income if not for the nonrecurring event, which gives them hope for the next quarter. On http://biz.yahoo.com/fin/l/e/extr_ai.html we even see that in the year ending July 2000 they paid $10M in income taxes, which tells us that maybe they know how that feels and want to do it again some day. I like EBITDA as a yardstick for measuring one company against another if they are otherwise similar and I'm looking for a differentiator. But I don't personally buy stock based on EBITDA numbers -- I want to see actual net income and, paradoxically, I love a company who has to pay income tax because it means they had INCOME to pay taxes on. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNX)
