Re: cooling door

2008-03-29 Thread Alex Pilosov

On 29 Mar 2008, Paul Vixie wrote:

 
 page 10 and 11 of http://www.panduit.com/products/brochures/105309.pdf
 says there's a way to move 20kW of heat away from a rack if your normal
 CRAC is moving 10kW (it depends on that basic air flow), permitting six
 blade servers in a rack.  panduit licensed this tech from IBM a couple
 of years ago.  i am intrigued by the possible drop in total energy cost
 per delivered kW, though in practice most datacenters can't get enough
 utility and backup power to run at this density.  if cooling doors
 were to take off, we'd see data centers partitioned off and converted to
 cubicles.
Can someone please, pretty please with sugar on top, explain the point
behind high power density? 


Raw real estate is cheap (basically, nearly free). Increasing power
density per sqft will *not* decrease cost, beyond 100W/sqft, the real
estate costs are a tiny portion of total cost. Moving enough air to cool
400 (or, in your case, 2000) watts per square foot is *hard*.

I've started to recently price things as cost per square amp. (That is,
1A power, conditioned, delivered to the customer rack and cooled). Space
is really irrelevant - to me, as colo provider, whether I have 100A going
into a single rack or 5 racks, is irrelevant. In fact, my *costs*
(including real estate) are likely to be lower when the load is spread
over 5 racks. Similarly, to a customer, all they care about is getting
their gear online, and can care less whether it needs to be in 1 rack or
in 5 racks.

To rephrase vijay, what is the problem being solved?

[not speaking as mlc anything]



[admin] [summary] RE: YouTube IP Hijacking

2008-02-25 Thread Alex Pilosov

A bit of administrativia:

This thread generated over a hundred posts, many without operational 
relevance or by people who do not understand how operators, well, operate, 
or by people who really don't have any idea what's going on but feel like 
posting. 

I'd like to briefly summarize the important things that were said. If you 
would like to add something to the thread, make sure you read this post in 
entirety.

Sorry if I didn't attribute every suggestion to a poster.

Facts:

* AS17557 announced more specific /24 to 3491, which propagated to wider 
internets

* Chronology (by [EMAIL PROTECTED])
http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube.shtml

* Things suggested to possibly address the problem:

** IRR filtering (using IRRPT http://sourceforge.net/projects/irrpt/ to 
generate filter lists)

** Notification when origin of a given route changes 
http://www.cs.ucla.edu/~mohit/cameraReady/ladSecurity06.pdf
http://www.ris.ripe.net/myasn.html
http://cs.unm.edu/~karlinjf/IAR/index.php (from pgBGP)

** pgBGP to depref suspicious routes 
http://www.nanog.org/mtg-0606/pdf/josh-karlin.pdf (unclear the number of 
false positives that will adversely affect connectivity)

** sbgp/sobgp - require full authentication for each IP block, and thus 
unlikely to be implemented until certificate chains are in place, and 
vendors release code that does verification, and operators are happy 
enough running it.

Other things addressed:

* Fragility of Internet: 

** Nobody brought up the important point - the BGP announcement filtering
are only as secure as the weakest link. No [few?] peers or transits are
filtering large ISPs (ones announcing few hundred routes and up). There
are a great many of them, and it takes only one of them to mess up 
filtering a downstream customer for the route to be propagated.

** Paul Wall brought up the fact that even obviously bogus routes (1/8 and
100/7) were accepted by 99% of internet during an experiment. Will it take
someone announcing 9/11 to get us to pay attention? (ok, bad joke)

** What I'd like to see discussed: Issues of filtering your transit
downstream customers, who announce thousands of routes. Does *anyone* do
it?

* Typos vs Malicious announcements

** Some ways of fixing the problem (such as IRR filtering) only address 
the typos or unintentional announcements. There's full agreement that IRR 
is full of junk, which is not authenticated in any sort. 

** Things like PHAS won't work if hijacker keeps the origin-AS same (by 
getting their upstream to establish session with different ASN)

** What I'd like to see discussed: Who (ICANN/RIRs/LIRs) is actively 
working on implementing chain of trust of IP space allocations?

* Ways to address the issue without cooperation of 3491: 
** Filtering anything coming out of 17557
** Suggestions given: 
** What I'd like to see discussed: Can an network operator, *today*,
filter the possibly bogus routes from their peers, without manual
intervention, and without false positives?

* Yelling at people who don't filter

** Per above, 3491 isn't the only one who filters. In fact, claims 
were made that *nobody* filters large enough downstreams. (beyond 
aspath/maxpref)

** *please* do not post additional comments about pccw bad, etc.

* Malicious vs mistaken on part of AS17557 and 3491:

** *please* do not post speculation unless you have facts to back it up.

** Any discussions of cyber-jihad are off-topic unless you can produce the 
fatwa to back it up.





Re: [admin] [summary] RE: YouTube IP Hijacking

2008-02-25 Thread Alex Pilosov

On Mon, 25 Feb 2008, Danny McPherson wrote:

  ** Paul Wall brought up the fact that even obviously bogus routes (1/8
  and 100/7) were accepted by 99% of internet during an experiment.
 
 I'm not sure why this would surprise anyone.
To me and you, it's not surprising. To public, it might be. Even the 
majority of nanog attendees I think would be surprised. 

  ** What I'd like to see discussed: Issues of filtering your transit
  downstream customers, who announce thousands of routes. Does *anyone*
  do it?
 
 Lots of folks do.  The interesting bit is that even then, those same
 providers would accept perhaps even those customer routes from their
 peers implicitly.
Well, in this case, they *aren't* filtering! (unless I am misunderstanding
what you are saying, due to repeated use of 'their').

  ** Things like PHAS won't work if hijacker keeps the origin-AS same
  (by getting their upstream to establish session with different ASN)
 
 NO, that's not even necessary.  Simple originate the route from the
 legit AS, and then transit it with the local AS as a transit AS. AS path
 manipulation is trivial.
Oh yeah, d'oh! Thanks for correction. But that is also an important point
against PHAS and IRRPT filtering - they are powerless against truly
malicious hijacker (one that would register route in IRR, add the
right origin-as to AS-SET, and use correct origin).

  ** What I'd like to see discussed: Who (ICANN/RIRs/LIRs) is actively
  working on implementing chain of trust of IP space allocations?
 
  * Ways to address the issue without cooperation of 3491:
  ** Filtering anything coming out of 17557
 
 Bad idea.
Obviously :)

  ** Suggestions given:
  ** What I'd like to see discussed: Can an network operator, *today*,
  filter the possibly bogus routes from their peers, without manual
  intervention, and without false positives?
 
 Sure, if they want to dedicate an engineer to it, automate policy
 deployment and deal with brokenness by turning steam valves.
I'd hear to see who does it, and get them to present the operational 
lessons at the next nanog!

  * Yelling at people who don't filter
 
 That's been productive for over a decade now.
 
  ** Per above, 3491 isn't the only one who filters. In fact, claims
  were made that *nobody* filters large enough downstreams. (beyond
  aspath/maxpref)
 
 Wrong.
Likewise, I'd like to know who does this (names) and how can we get them
to present best practices at the next nanog!

-alex



[admin] Re: Fourth cable damaged in Middle Eest (Qatar to UAE)

2008-02-04 Thread Alex Pilosov

This conversation is quickly spinning into discussion of politics and
terrorism.

Reminder to all, please stick to the *operational* aspects of this thread.

-alex [NANOG MLC Chair]

On Mon, 4 Feb 2008, Patrick Clochesy wrote:

 I disagree... I think information warfare tactic could easily be
 terrorism, though I can't see why this particular event could/would be
 terrorism.
 
 Disrupting a major network like the Internet WITHIN the US could
 definitely be a form of terrorism... I think anything which maliciously
 disrupts a huge portions of a nation's day-to-day activities would be
 cause for concern for many folk, especially the telecommunications
 infrastructure. However, I'm not sure what the mindset of the terrorist
 would be even if they fully succeeded what is proposed would be the
 terrorist's plan - even if we lost totally connectivity with the middle
 east, or even what's considered friendly countries... as long as the
 information is flowing at home, nobody's going to be filling their
 swimming pools full of drinking water.
 
 I imagine the mindset would be different if you were a small country
 loosing a substantial portion of it's communication channels with the
 outside world...
 
 -Patrick 
 
 - Original Message - 
 From: Mark Newton [EMAIL PROTECTED] 
 To: Martin Hannigan [EMAIL PROTECTED] 
 Cc: Sean Donelan [EMAIL PROTECTED], nanog@merit.edu 
 Sent: Sunday, February 3, 2008 11:12:46 PM (GMT-0800) America/Los_Angeles 
 Subject: Re: Fourth cable damaged in Middle Eest (Qatar to UAE) 
 
 
 
 On 04/02/2008, at 4:38 PM, Martin Hannigan wrote: 
 
  I agree with Rod Beck as far as the speculations go. It could be 
  terror, 
 
 Well, no, it couldn't be. Nobody is being terrorized by this. How 
 can it possibly be a terrorist incident? 
 
 If it's deliberate, it might be described as an information warfare 
 tactic. But not terrorism. 
 
 (visions of some guy sitting a in cave with a pair of wet boltcutters 
 laughing maniacally to himself, cackling, Ha-ha! Now their daytraders 
 will get upset, and teenagers will get their porn _slower_! Die 
 American scum! Doesn't really work, does it?) 
 
 Politicians have succeeded in watering down the definition of the word 
 terrorism to the point where it no longer has any meaning. But we're 
 rational adults, not politicians, right? If we can't get it right, 
 who will? 
 
 - mark 
 
 
 



RE: Blackholes and IXs and Completing the Attack.

2008-02-03 Thread Alex Pilosov

On Sat, 2 Feb 2008, Tomas L. Byrnes wrote:

 I sincerely doubt that any backbone provider will filter at a /32. That
 means they have to check EVERY PACKET AT FULL IP DEST against your AS
 advertised routes. Since most backbone routers build circuits at the /18
 and above mask on MPLS, just to keep up with traffic, I sincerely doubt
 they are going to expend the CPU, and potentially RAM, never mind prefix
 table entries (you know, those things we're running out of) to have a
 full table of every host that every hoster says is being DDOSed. In this
 case, there's a clear economic cost, for no economic benefit (they do
 actually make money delivering that DDOS traffic).
most backbone routers build circuits at the /18 and above mask on MPLS - 
that part is seriously funny.

However:
a) Yes, if such proposal was to be widely accepted, it would generate more 
entries in RIB/FIB.

b) However, if this service was actually operated by IX's, the limits to
prevent too much growth could be applied centrally (max-prefixes per 
ASN, automatic removal of those routes after X days, unless manually 
requested by host, etc).

c) Since only your peers will have those :666 entries, it is less route
growth than than the alternative of announcing the affected block as /24 
(which you seem to suggest).

 A better approach would be to move your DDOS target and all the rest of
 its co-subnet hosts into a different /24, update the DNS RRs, and cease
 advertising that /24. 
That...is...perverted. Not to mention, you can't cease advertising /24. 
what you would need to do is to deaggregate your (say) /20 into /21, /22, 
/23 and /24. That's 3 extra entries in FIB for everyone in the world to 
carry.

 If you really want to be nice, they don't need to renumber, you just
 need to stop advertising the target subnet, change the DNS RR's and NAT
 at your borders, if you control DNS and IP. The added benefit of this is
 that you can swap them back when the DDOs is over, and they get to stay
 up while it's happening. All you need to do this is some spare, never to
 be allocated, IP space.
That...is...perverted.

-alex [not speaking as mlc anything]



Re: Off Topic

2008-01-15 Thread Alex Pilosov

On Tue, 15 Jan 2008, Rod Beck wrote:

 At the risk of incurring Mr. Pilosoft's wrath (the Putin of NANOG?),
You meant the srh of nanog. And I'm not ;)

 I'll looking for NANOG style ISP meetings to attend in Europe this year
 (France, Germany, UK, Belgium, and Netherlands). Any suggestions would
 be appreciated. Please bypass the list and send them directly to me.
The first thing that comes to mind is RIPE. Next thing that comes to mind 
is UKNOF.

Also, that isn't really off-topic. However, if you get off-list replies, 
could you please do a follow-up summary post and list the european neteng 
groups, that would be quite helpful. A good starting point for the search 
is www.euro-ix.net, which lists european IXPs. Many IXP's have annual (or 
more often) meetings of members, which serve similarly to NANOG. See: 
https://www.euro-ix.net/news/meetevent/ for starters.

-alex



[admin] RE: Creating a crystal clear and pure Internet

2007-11-27 Thread Alex Pilosov

On Tue, 27 Nov 2007, Jerry Pasker wrote:

 
 
 But, if it's not viewed as political then...
 
 Your analogy is flawed, because the Internet is not a pipe system
 and ISP's are not your local water utility.
 
 And the internet is not a big truck!  It'sIt's a series of tubes!
 
 Sorry, I couldn't resist... with all these things clogging all the
 tubes.  :-)
I'd like to draw attention to nanog AUP, particularly #6: Postings of
political, philosophical, and legal nature are prohibited.

While the regulation of internet by filtering bad traffic is clearly
political and/or legal, I do think the *technical* implication of it are 
very much on-topic. After all, once this happens, we as network operators 
will be responsible for the filtering.

Given that, I'd like to ask everyone to refrain off-hand comments about
tubes and dump trucks - we all hear this joke every day. Discussion of 
morality of such filtering is also off-topic.  

Discussion of implementation of such filtering and effect of it on network
operations at-large is clearly on-topic. Discussion of separating traffic
(by network operators) into bad and good is also on-topic.

The list is about technology and operations. This is not ITU. This is not
C-SPAN. This is not 'general banter among network operators' list either.
 
Before you post to the list, think - would you want to make a presentation
at NANOG-conference based on your post? If it doesn't feel appropriate,
the list post is similarly inappropriate.

Also, this is another reminder that MLC *will* be giving formal warnings
(which will eventually lead to removal from the list) to those who 
continue to post off-topic messages.

As usual, should you wish to discuss this post, please do so on 
nanog-futures (reply-to has been set accordingly).

Thanks!

-alex [mlc chair]



[admin] Re: unwise filtering policy from cox.net

2007-11-20 Thread Alex Pilosov

On Tue, 20 Nov 2007 [EMAIL PROTECTED] wrote:

 On Tue, 20 Nov 2007 11:21:19 PST, [EMAIL PROTECTED] said:
  This seems a rather unwise policy on behalf of cox.net -- their
  customers can originate scam emails, but cox.net abuse desk apparently
  does not care to hear about it.
 
 Seems to be perfectly wise if you're a business and care more about
 making money than getting all tangled up in pesky things like morals and
 ethics. It's great when you can help the balance sheet by converting
 ongoing support costs and loss of paying customers into what
 economists call externalities (in other words, they make the
 decisions, but somebody else gets to actually pay for the choices made).
This is one of the threads where posting further will not be productive.  

Cox abuse has been named and shamed, and hopefully, the next post we see
to the thread will be from them.

As a reminder, political discussions, and discussions about spam filtering
(other than operational, such as abuse@ or [EMAIL PROTECTED]) are off-topic for
nanog. Please keep it this way.

-alex [mlc chair]



Re: Getting DSL at your datacenter for OOB

2007-11-07 Thread Alex Pilosov

On Wed, 7 Nov 2007, David Ulevitch wrote:

 We had a great experience doing this with Sonic.net at PAIX in Palo Alto
 but have had no success at our other sites. (Sonic.net isn't a national
 DSL provider)
 
 Has anyone found providers who can provision DSL circuits at: EQNX ASH,
 the MMR at 111 8th, and the Westin in Seattle?  Speakeasy, after trying
 valiantly, finally just gave up saying they just couldn't make it
 happen.
It's not rocket science. You order POTS line from the LEC. Then you order
DSL from your favorite shared-line DSL provider on that POTS line. 

Trying to get non-lineshared-dsl might be a challenge. 

However, I recommend POTS + DSL, for additional OOB-ness, you can plug
your DSL modem into the OOB ethernet and your analog modem into OOB serial
network.

fwiw, we are providing dsl to 111 8th MMR, the one running the free wifi
there :)


-alex [not posting as mlc anything]



Re: Fwd: [nanog-admin] Vote on AUP submission to SC

2007-10-31 Thread Alex Pilosov
On Wed, 31 Oct 2007, Sean Figgins wrote:

  I also think this needs additional language to ensure that it is
  within the realm of the authority of the MLC/NANOG.  NANOG has no
  authority to prohibit autoresponses that result in a direct email to
  someone on the list.  Without this language, you will have a lot of
  people continuing to whine about getting an autoresponse when they CC
  everyone in the thread and one of them is on vacation.
  
  Since this is the lists' AUP, whatever consenting adults do to their
  private email that has no bearing to the list is clearly OK.

 I already know of one case that someone that CCed nanog@ and the
 original poster complained when they got an autoresponder.  The proposed
 language is vague enough that it does not make it clear if it applies
 only to messages send through the list, or a message to any individual
 that includes the list.  If you all want to live in a vague world, then
 that's fine by me, but don't complain when you get complaints that arise
 out of the vagueness.
Well, that's why MLC is paid big bucks to separate loony complaints from 
real ones ;)


-alex



Re: mail operators list

2007-10-30 Thread Alex Pilosov

On Wed, 31 Oct 2007, Suresh Ramasubramanian wrote:

 Well, the current nanog MLC is mostly because Susan Harris was cracking
 down equally on discussions of anything mail / spam filtering related
 (operational not kooky) .. in fact, on anything that didnt involve
 pushing packets from A to B.
 
 And we have Marty Hannigan from the MLC telling us that operational mail
 / spam filtering issues are perfectly on topic.  New list not
 particularly necessary I think .. but sure, a spam or mailops bof at
 nanog would be a good idea. I (or well, APCAUCE) have been running a
 spam conference track at APRICOT for the past few years now ..
This has veered from operational discussion into the realm of
meta-discussion about the list, so let's move it to nanog-futures.  
Reply-to has been set accordingly in this email, please respect it.

MLC's position is that anything that is acceptable for the conference is 
acceptable on the list. Mail operations are on-topic, although 
tangentially. Spam filtering is definitely off-topic. 


-alex [mlc chair]



Re: ARPANet Co-Founder Predicts An Internet Crisis (slashdot)

2007-10-25 Thread Alex Pilosov

On Thu, 25 Oct 2007, Paul Vixie wrote:
 
 Dr. Larry Roberts, co-founder of the ARPANET and inventor of packet
 switching, predicts the Internet is headed for a major crisis in an
 article published on the Internet Evolution web site today. Internet
 traffic is now growing much more quickly than the rate at which router
 cost is decreasing, Roberts says. At current growth levels, the cost of
 deploying Internet capacity to handle new services like social
 networking, gaming, video, VOIP, and digital entertainment will double
 every three years, he predicts, creating an economic crisis. Of course,
 Roberts has an agenda. He's now CEO of Anagran Inc., which makes a
 technology called flow-based routing that, Roberts claims, will solve
 all of the world's routing problems in one go.
 
 http://slashdot.org/article.pl?sid=07/10/25/1643248
I don't know, this is mildly offtopic (aka, not very operational) but the
article made me giggle a few times.

a) It resembles too much of Bob Metcalfe predicting the death of the
Internet. We all remember how that went (wasn't there NANOG tshirt with 
Bob eating his hat?)

b) In the words of Randy Bush, We tried this 10 years ago, and it didn't 
work then. Everyone was doing flow-based routing back in '90-95 (cat6k 
sup1, gsr e0, first riverstoned devices, foundry ironcore, etc). Then, 
everyone figured out that it does not scale (tm Vijay Gill) and went to 
tcam-based architectures (for hardware platforms) or cef-like based 
architectures for software platforms. In either case, performance doesn't 
depend on flows/second, but only packets/second.

Huge problem with flow-based routing is susceptibility to ddos (or
abnormal traffic patterns). It doesn't matter that your device can route
1mpps of normal traffic if it croaks under 10kpps of ddos (or
codered/nimda/etc).

-alex [not mlc anything]

[mlc]




[admin] Re: Can P2P applications learn to play fair on networks? and Re: Comcast blocking p2p uploads

2007-10-22 Thread Alex Pilosov

On Mon, 22 Oct 2007, Randy Bush wrote:

 actually, it would be really helpful to the masses uf us who are being
 liberal with our delete keys if someone would summarize the two threads,
 comcast p2p management and 204/4.
240/4 has been summarized before: Look for email with MLC Note in 
subject. However, in future, MLC emails will contain [admin] in the 
subject.

Interestingly, the content for the p2p threads boils down to:

a) Original post by Sean Donelan: Allegation that p2p software does not
play well with the rest of the network users - unlike TCP-based protocols
which results in more or less fair bandwidth allocation, p2p software will
monopolize upstream or downstream bandwidth unfairly, resulting in
attempts by network operators to control such traffic.

Followup by Steve Bellovin noting that if p2p software (like bt) uses
tcp-based protocols, due to use of multiple tcp streams, fairness is
achieved *between* BT clients, while being unfair to the rest of the 
network. 

No relevant discussion of this subject has commenced, which is troubling, 
as it is, without doubt, very important for network operations.

b) Discussion started by Adrian Chadd whether p2p software is aware of
network topology or congestion - without apparent answer, which leads me 
to guess that the answer is no.

c) Offtopic whining about filtering liability, MSO pricing, fairness,
equality, end-user complaints about MSOs, filesharing of family photos,
disk space provided by MSOs for web hosting.

Note: if you find yourself to have posted something that was tossed into
the category c) - please reconsider your posting habits.

As usual, I apologise if I skipped over your post in this summary. 

-alex



[admin] Re: Can P2P applications learn to play fair on networks? and Re: Comcast blocking p2p uploads

2007-10-21 Thread Alex Pilosov

[note that this post also relates to the thread Re: Comcast blocking p2p 
uploads]

While both discussions started out as operational, most of the mail
traffic is things that are not very much related to technology or
operations.  

To clarify, things like these are on-topic:

* Whether p2p protocols are well-behaved, and how can we help making 
them behave.

* Filtering non-behaving applications, whether these are worms or p2p 
applications.

* Helping p2p authors write protocols that are topology- and
congestion-aware

These are on-topic, but all arguments for and against have already been
made. Unless you have something new and insightful to say, please avoid
continuing conversations about these subjects:

* ISPs should[n't] have enough capacity to accomodate any application, no 
matter how well or badly behaved
* ISPs should[n't] charge per byte
* ISPs should[n't] have bandwidth caps
* Legality of blocking and filtering

These are clearly off-topic:
* End-user comments about their particular MSO/ISP, pricing, etc. 
* Morality of blocking and filtering

As a guideline, if you can expect a presentation at nanog conference about
something, it belongs on the list. If you can't, it doesn't. It is a clear
distinction. In addition, keep in mind that this is the network
operators mailing list, *not* the end-user mailing list.

Marty Hannigan (MLC member) already made a post on the Comcast blocking
p2p uploads  asking to stick to the operational content (vs, politics and
morality of blocking p2p application), but people still continue to make
non-technical comments.

Accordingly, to increase signal/noise (as applied to network operations)  
MLC (that's us, the team who moderate this mailing list) won't hesitate to
warn posters who ignore the limits set by AUP and guidance set up by MLC.

If you want to discuss this moderation request, please do so on 
nanog-futures.

-alex [mlc chair]



RE: 240/4 (MLC NOTE)

2007-10-18 Thread Alex Pilosov

Guys, this thread has gone over 50 posts, and doesn't seem to want to end. 

By now, everyone has had a chance to advance their argument (at least
once), and we are just going in circles, increasing noise and not
contributing to signal.

I'd like to summarize arguments advanced - and if you don't have something
new (not listed here) to say, can you please avoid posting to this thread?

If you disagree with me, please take it to nanog-futures.

Summary of arguments:

In favor of experimental use only:
Alain Durand: at your own risk, this stuff can blow up your network

In favor of private use: 
Randy Bush: if it works for you, why mark it experimental
Dillon: why shouldn't people use it if they can

In favor of no use at all:
Joe Greco: it doesn't work now (today) on current-generation OSes, there
is no chance to get it to work in any shape of form by the time v4 space
is exhausted.
Steve Wilcox: it will never work

Mixed:
Daniel Senie: Allocate some as private, reserve rest as 'allocatable' once 
vendors get the gear fixed to accomodate those who use as private

Additional points:
David Ulevitch: If it is ever designated rfc1918, it cannot ever become 
public.

Many: It will buy us some time before v4 address space is 
exhausted, and much less painful than v6 deployment

Many: Old gear cannot be v6-enabled, but it can be 240-enabled

Dillon: This is not our decision, this is IETF/IANA decision.

-alex [mlc chair]



Re: autoresponders

2007-10-17 Thread Alex Pilosov
On Wed, 17 Oct 2007, Lynda wrote:

 I'm on a couple of lists where the reply-to header is munged in just
 this way. I hate it. I much prefer the extra effort that says to send to
 the list, rather than constantly checking to make sure that a private
 message is not being sent to the list by accident.
FWIW, IMHO, I agree 100%. 

 Sean, not picking on you, but this touched a nerve. Out of control
 vacation (and other autoresponder) programs should be dealt with one at
 a time, as needed. There's already enough rules.
As they are. I've asked [EMAIL PROTECTED] for rough number of subscribers that
have 'no longer with the company' autoresponder that gets unsubscribed by
her based on complaints by list subscribers - the answer is between 0.5 to
2 per month - seems low, however, if we stop doing it, a year later,
you'll get between 6 and 24 autoresponder replies to each post. Which 
would be bad (tm).

-alex



Re: NANOG Elections

2007-10-16 Thread Alex Pilosov
Question, I wonder if we can get statistics on how many people who have 
registered at this nanog have voted vs those who are not physically here?

This would help determine if putting a voting desktop outside of main
conference room help increase voting participation?

Also, possibly, instead of posting to -announce, a direct email to
last-registered-email should be sent to each eligible voter reminding them
to vote - Some people who attend aren't on any mailing list. (actually, it
is an interesting data point, but probably impossible to gather correct
data on).

-alex



kill thread (Re: wanted: offshore hosting)

2007-10-09 Thread Alex Pilosov

On Tue, 9 Oct 2007 [EMAIL PROTECTED] wrote:

 Hello all.
 
 Last time I asked for a hosting place, I ended up going with
 LayeredTech, but I can give you a list of options if you like.
snip

Please note that this thread is off-topic for nanog-list. Please do not 
contribute further to this thread. 

Reasons for offtopic-ness:

a) not internet operational
b) commercial
c) end-user


-alex [mlc chair]



Re: mlc files formal complaint against me

2007-10-08 Thread Alex Pilosov
On Mon, 8 Oct 2007, vijay gill wrote:

 Really, reading this thread has left me stupider. I guess instead of
 focusing on things like the lightweight agenda, abysmal content and
 actual value to be had from NANOG, we are getting tied up discussing an
 offhand remark about a convicted felon. I submit that nanog as a whole
 is stupider under this formal SC/MLC/PC/whatever than when it was under
 the benevolent dictatorship of Susan.
It takes Vijay to cut to the core of the issue and drop science like 
bombs. 

Sometimes benevolent dictatorship is much better at getting things done.

 Never was the old adage about people getting the government they deserve
 truer than it is now. We have become a legion of whiners, focused less
 on the work and more on the process and protocols of etiquette than
 building networks, though that is probably something a cisco SE can
 crank out from a visio template faster and in most cases, better than
 most participants in this trainwreck.
This is something that could be on nanog tshirt, trainspotting style. 

 I suggest with the best intention possible that marty unwad his shorts
 and the rest of us STFU and GBTW.
I'll add others to the list, but yes, in the simplest possible terms, this
thread was a ridiculous waste of time of everyone involved.

-alex



Re: Anyone using uvlan out there?

2007-09-13 Thread Alex Pilosov

On Fri, 14 Sep 2007, Steven Haigh wrote:

  From my understanding, this software is pretty much acting like a
 bridge, but with endpoints over a routed IP network.
So its like l2tpv3 vpn. 

And, since its based on PC platform, I kind of have to say, in words of
Vijay, It does not scale, and What problem is being solved?

-alex [not mlc anything]



RE: Using Mobile Phone email addys for monitoring (summarization)

2007-09-07 Thread Alex Pilosov

As an experiment, I wanted to try to summarize all the answers given on 
this question, hope this helps someone.

Suggestions given:

* modem and TAP gateway 
** TAP numbers at  http://www.avtech.com/Support/TAP/index.htm
** Software: sendpage or qpage

* Mobile phone with a serial port and AT commandset
** Software: sms-tools gnokii gsmd
** Issues: not reliable because of battery drain

* Purpose-made GSM/CDMA modems 
** Software: same as above
** Manufacturers: Intercel, Sierra 750 (PCMCIA), Falcom Samba 75 (USB)

* Purpose-made GSM-IP modems
** Manufacturers: http://www.acmesystems.it/?id=70

* Pages via DTMF 
** Hylafax/asterisk

-alex [for mlc]



Re: Using Mobile Phone email addys for monitoring

2007-09-06 Thread Alex Pilosov

On Thu, 6 Sep 2007, matthew zeier wrote:

 Recommendations on software and modems?
Couple of options:

Dedicated cell phone connected via serial cable and gnokii-like software

Analog modem and voice line and TAP software (like sendpage or qpage)

Technically, SNPP is the appropriate solution, but might be overkill if 
you just have a single host sending messages.

-alex [not nanog mlc blah blah]



NANOG Humour (Re: 2M today, 10M with no change in technology? An informal survey.)

2007-08-27 Thread Alex Pilosov

On Mon, 27 Aug 2007, Hex Star wrote:

 On 8/27/07, Justin M. Streiner [EMAIL PROTECTED] wrote:
 
 
 
   I thought it was just a 6500 that sommeone got drunk and tipped over on
   it's side, like a cow...
 
 
 
 
 http://farm.tucows.com/images/2006/07/cow_tipping.jpg :D
While its occasionally amusing, can we please keep the humour to the
minimum, while sticking to the operational content?

-alex (mlc chair)



Re: 2M today, 10M with no change in technology? An informal survey.

2007-08-27 Thread Alex Pilosov

On Mon, 27 Aug 2007, Jon Lewis wrote:

 Though if you've kept up with the latest IOS developments, cisco is
 finally differentiating the platforms we've assumed for years were only
 different in angle and paint.  6500's won't get to run the newest 7600
 code.
I think Cisco is coming to their senses. SXH has *most* of SRB features, 
while (hopefully) more stable.

At this point, imho, the rsp720 is getting the short end of the stick, 
because it is only limited to SRB+, while you have a choice of SX* and SRB 
on the sup720.

But I think, imho, this discussion belongs to cisco-nsp more than to
nanog-l.

-alex [not speaking as mlc blah blah]



Kill this thread (Re: DNS not working)

2007-08-17 Thread Alex Pilosov

I think this thread is obviously silly, so please refrain from posting 
further on this and feeding the troll...

Thanks!


On Thu, 16 Aug 2007 
[EMAIL PROTECTED] wrote:

 
 
 Hi, I try adding google.com to my dns server to get more visitors but 
 google.com still show search engine. Please advise how to do so more visitor 
 in return? May the Gods be with you!
 



Re: Link to wiki?

2007-08-10 Thread Alex Pilosov
On Fri, 10 Aug 2007, Lynda wrote:

 Resending, using merit, since nanog.org doesn't seem to be working...
fyi, I received the previous one sent through nanog.org 

 
 I note that the (sadly outdated) FAQ is still listed on the web site,
 and that there isn't a pointer to the Wiki... I had been planning on
 spending a bit of time trying to reconcile the two (i.e. take some of
 the still useful bits from the FAQ to the Wiki), which is what made me
 sit up and take notice.
 
 Perhaps a link would be in order?
agree. I'll ask Merit webmaster to update website.

I think it should be a Wiki link below the Maling list  FAQ.

-alex



Please stop (Re: Gwd: crypted document)

2007-08-02 Thread Alex Pilosov

On Thu, 2 Aug 2007, Chris Adams wrote:

 
 Once upon a time, Jon Lewis [EMAIL PROTECTED] said:
  If you could read the header, the question you would have asked is, What 
  is Chris Adams doing in Korea sending virus mail to nanog?  :)
 
 Especially as this particular Chris Adams is not well traveled and has
 never been west of the Mississippi!
I think at this point, its fairly clear what happened (fake sender, reply
that went to list etc) so continued discussion is rather fruitless. 

Lesson to be learned: You cannot protect from human factors. :(

-alex (mlc chair)



EPO/NEC (was Re: Why do we use facilities with EPO's?)

2007-07-25 Thread Alex Pilosov

On Wed, 25 Jul 2007, Leo Bicknell wrote:

 What I found interesting is that a single EPO is not a hard and fast
 rule.  They walked me through a twisty maze of the national electric
 code, the national fire code, and local regulations. Through that
 journey, they left me with a rather interesting tidbit.

 The more urban an area the more likely it is to have strict fire
 codes.  Typically these codes require a single EPO for the entire
 structure, there's no way to compartmentalize to rooms or subsystems.
 However in more rural areas this is often not so, and they had in fact
 built data centers to code WITHOUT a single building EPO in several
 locations.  That's to say there was no EPO, but that it may only affect
 a single room, or even a single device.
 
 If they can be avoided, why do we put up with them?  Do we really
 want our colo in downtown San Francisco bad enough to take the risk
 of having a single point of failure?  How can we, as engineers, ask
 questions about how many generators, how much fuel, and yet take
 for granted that there is one button on the wall that makes it all
 turn off?  Is it simply that having colo in the middle of the city
 is so convenient that it overrides the increased cost and the reduced
 redundancy that are necessitated by that location?
This is an interesting question.

National Electric Code (NEC) requires EPO. Sort of. Articles 645 and 685
deal with it.

While NEC is not binding on every jurisdiction, almost every US
jurisdiction bases its code on NEC with additions/subtractions. I don't 
know offhand if the local changes deal with EPO much, however, here's some 
food for thought regarding EPO and NEC.

With regard to putting up with them - EPOs are designed to protect life,
not property or uptime. If there's a short causing electrical fire because
breaker did not open, firefighter better be sure he can cut the power
*before* stepping next to it.

Here's how NEC works:

1) If a room is designed to comply with Article 645, it must have EPO, 
*except* if it qualifies under Article 685.

Being under Article 645 gives couple of things that are generally not 
permitted otherwise, as follows:

645.4 D) permits underfloor wiring for power, receptacles and 
crossconnects.

645.4 E) Power cables;  comunications cables; connecting cables;
interconnecting cables; and associated boxes, connectors plugs and
receptacles that are listed as part of, or for, information technology
equipment shall not be required to be secured in place.

In other words, you can have crossconnects that are laying on the floor
(or under raised floor but not otherwise secured), and that is OK, 
normally they'd need to be secured every X feet.

645.17) (too lazy to retype NEC language) You can have PDUs with multiple 
panelboards within a single cabinet - not all that clear what exactly 
does it permit (PDUs with multiple breaker panels essentially).

My understanding is that if you are willing to forego things that 
Article 645 permits, you do not have to install EPO. Frankly, I don't see 
all that much logic in 645 requirements and linking it to EPO (except, 
possibly, to make operation of datacenters not in compliance with 645 to 
be annoying enough that everyone would opt to comply with EPO).

The Article 685 exception from EPO applies if An orderly shutdown is
required to minimize personnel hazard and equipment damage. It is really
intented for industrial (like chemical plants control) systems where EPO
shutoff can cause damage to life/property. I doubt this applies to 
datacenter.

Above is an armchair engineer's understanding. To be sure, you should 
consult a real engineer who can stamp and seal your plans!

-alex