AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Michael.Gollotti@lsi.com>,<Richard.Hardiman@lsi.com>,<brian.stark@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	B50ED5C0A7967343B07C1764EE1D7BD1F50043FC@cosmail01.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 5 Jan 2010 11:56:32 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Gollotti, Michael" <Michael.Gollotti@lsi.com>
Bcc: Richard Hardiman <Richard.Hardiman@lsi.com>, Brian Stark
 <brian.stark@lsi.com>
Subject: Re: Campbell E-Lab Discussion and Planning Meeting
Message-ID: <20100105115632.7b895bc8@ripper.onstor.net>
In-Reply-To: <B50ED5C0A7967343B07C1764EE1D7BD1F50043FC@cosmail01.lsi.com>
References: <B50ED5C0A7967343B07C1764EE1D7BD1F50043FC@cosmail01.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Michael,

Maybe the best thing to do is have a pre-meeting meeting or a phone call
or something.  I know I'm new to LSI, but I'm not getting why this is
such a big production, with so many external people involved.

First thing is we need to get a couple of the in-rack switches over
here... today would not be too soon.  Can that be arranged?  We need
them for work that is waiting for the functionality of those switches.

Secondly, I don't see why we can't get all the switches sent over here
right now, and start installing them now, without any big meeting.
Sure they may be only screwed into the racks for a day or so, but once
they're in, the wiring and the configuring and whatnot can happen at
any time.

Also, there seems to be some confusion regarding who "owns" or is
responsible for the switchesses.  I think it's us, but Rich Miller said
that was not his understanding (and someone else on the conference call,
a woman I don't know, who said the same thing as Rich, only she used
the phrase "we have always been responsible for all ESG lab switches").
The thought was that we should talk to Karen to confab on that issue,
which my boss, Brian Stark, has on his plate.  I don't think it's
happened yet.

We're definitely not planning on re-IPing the lab at this time.  All
work would have to stop for a week to do that.  Mayb more than a week.
I've told Rich Hardiman, our lab manager, that I would like to stop
exporting lab IP addresses outside the building, as 10. IP addresses
are private and ...  well ... should be private.  We can configure the
switches that connect to the IT network to do what is necessary in
terms of NAT/DNS etc. So we still would need the IP space that IT wants
us to use for the lab.

One thing that I'm not sure everyone realizes, because this is the first
ESG product, that I know of, which has networking as an major part of
the product, is that the switches in the lab will be constantly
configured. We have to develope and test those networking features,
which will necessitate constant [re]configuration activity on those
switches. That is not something that we can delegate to some offsite
personell, it has to be performed and owned in house by not just the
lab manager folk (just Rich at the moment) but also by -- gasp --
actual engineers, who have to understand what our customers will be
doing, how they do it, and what that results in from the perspective of
the filer and what it needs to do.

The switches that connect to the IT network will have to have a
co-ownership state, and won't be subject to the constant waves of
reconfiguration.  They will be like normal IT switches: hardly ever
undergoing configuration cycles except at the beginning.


On Tue, 5 Jan 2010 11:21:52 -0700 "Gollotti, Michael"
<Michael.Gollotti@lsi.com> wrote:

> When: Thursday, January 07, 2010 9:00 AM-10:00 AM (GMT-08:00) Pacific
> Time (US & Canada). Where: Dial in#: 18-8888 or 1-866-214-7945
> Conference #: 408-954-3636
> 
> *~*~*~*~*~*~*~*~*~*
> 
> Discussion Points and Planning Meeting for Campbell E-Lab:
> 1.      Implement new Cisco hardware within lab with all new subnets
> (can be installed without affecting existing lab environment)
> -       Discuss Implementation Plan
> -       Discuss Timeline for Installation
> 2.      Verify new subnet requirements
> -       Spec SFS Testing & Performance
> -       Vlan 22 Management vlan
> -       Vlan 33 Data vlan
> -       Internal lab subnet (non-routed)
> 3.      Migrate existing hosts within lab to new subnets
> -       As hosts are migrated to new subnet space, relocate to new
> hardware infrastructure 4.      Decommission existing hardware as
> hosts are moved to new Cisco infrastructure
> -       Remove existing hardware from network rack and utilize for
> redundant connection to new Cisco hardware. Issues
> 1.      Hosts within lab have child and master scripts that are hard
> coded to the host___s IP address, not by host name
> -       Can hostnames be used going forward with new infrastructure?
> -       What timeframe is needed to migrate scripts to have either
> hostname or new IP scope? 2.      Verify new subnet requirements
> -       How many IP scopes will be needed?
> -       Current host count within lab?
> -       Future host count requirements?
> 3.      Migration plan for lab devices with fiber SFP___s to copper
> SFP
> 
> 
> 
