Doing Good

The report of the Virginia Tech Review Panel came out yesterday. It is 247 pages long and contains 93 specific recommendations. I would summarize my take-away like this:

• Do not let the existence of a procedure, policy, or even a law — no matter how well intentioned — be an excuse to not use your brain.

To apply that to IT folks:

• Do not build systems that prevent people from using their brains.

I am trying to phrase things positively, because they are easier to understand, so let me turn that around:

• IT people should build systems that enable and encourage people to use their brains.

Share: Delicious | Facebook

Hey! We have agile boot straps!

The other day, Kevin Morooney made an interesting blog post. I thought it contained a few useful nuggets. Kevin is talking about a podcast where Jon Udell speaks with Greg Elin, chief architect with the Sunlight Foundation:

The notion of agile development, not just as a software development methodology but also as a project management methodology was brought up again and again. I know there are folks in ITS and all over Penn State who are talking about and have embraced both concepts. We’re having lots of discussion about project management in ITS right now — I highly recommend a listen from that perspective too.

That was enough to get me interested.

I gave the podcast a listen and thought this passage was really relevent. In their discussion about development within the Sunlight Foundation, John and Greg are talking about a concept they call bootstrapping in regards to giving the public access to data:

Jon Udell There was always the notion that we would put this stuff out there, but we never really expected anyone would be interested or would want to do anything with it. And, you know, this notion that you can kind of bootstrap this process of getting people engaged with the data. At which point it actually creates a demand. People start to see the stuff — be able to work with it — and then, now we realize that we really did want public to mean something a little more.

Greg Elin John? You can come here and do my job. I mean, I think that’s an excellent articulation of it.

I think that, you know, the Internet also teaches us that you have to bootstrap things. You don’t want to. The big technology projects that fail are the projects where you have a long list of requirements and people are going to work for many years, or you have a very detailed [specification] of what the future is going to be like. And you know, those are the projects that they’re outdated before they launch. Whereas the Internet, where the approach of rough and ready consensus — let’s define the minimal amount of protocol that we need to standardize communication and let everybody have a go at it — and let it iterate really rapidly.

So now, I am interested. I do not want to manage the projects that fail. I want to learn more about agile development, which I had written off as just another fad. It turns out that a set of principles embodies the philosophy of agile development. I will paraphrase a few of them:

• Satisfy the customer through early and continuous delivery of valuable products and services

• Deliver working products and services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

• Continuous attention to technical excellence and good design enhances agility

• Simplicity — the art of maximizing the amount of work not done — is essential

• Working products and services are the primary measure of progress

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

My first reaction (not invented here) was, “Sure. That’s all well and good for you software types, but try that when you have to select a new router platform before you can even begin.” But I gave it a little more thought and realized that — perhaps by accident — we were actually already applying these principles.

Take the ITS Firewall Service as an example. When we initially developed the service, we had a specific application in mind. For that application, we made design assumptions — perfectly valid ones when taken in context — and we developed a service that satisfied that application. It turns out that those same assumptions make it less than suitable for many other applications.

Instead of starting over from scratch, we have been making a series of small changes that each contributes to a more useful service.

• In March, we made a private fiber rate exception. This allowed units to affordably collapse networks in multiple buildings — fed from a common hub — behind a single firewall.

• In May, we made a change to the policy on installation and maintenance of local area networks that added the option for full or hub-only maintenance networks behind a customer maintained firewall, giving units the options to provide their own firewall without losing TNS maintenance.

• In July, we made pricing changes to make the firewalls themselves more affordable.

• Now, we are working on a multi-port firewall service that will allow units to take advantage of more of the capabilities of the TNS maintained firewall.

These are all small steps. Each one designed to make the service more attractive to more people. Early and continuous delivery of valuable products and services. Working products and services, delivered frequently, from a couple of weeks to a couple of months. Well designed and technically excellent. Each kept simple. Showing progress with working products and services.

Wait a moment! We are agile!

If we had compiled a list of all the requirements for the perfect firewall service (we did) and waited until we had the perfect service before making anything available (we didn’t) then all of the people who have benefited from these changes would still be waiting. The project would have failed because it would have been outdated before we finished.

Of course, any time you pick one thing from a list as the thing you are going to do next, someone is going to be frustrated that you have not chosen the thing that they wanted. Perhaps that is where reflecting on how to become more effective comes into play.

Share: Delicious | Facebook

Multi-port Firewall Service Proposal

Points to be Addressed in a Proposal for a New Service:

1. Why is the proposed service believed to apply to the case at hand (what is the purpose for wanting to add the service, what are the user issues, what deficiency is thought to exist)?

   High-level authorities within Penn State have recently made strategic changes to the network firewall philosophy, dramatically increasing the demand for the ITS Firewall Service. In addition, changes to the Private Fiber policy have changed some of the design assumptions of the existing service, since departments can now collapse multiple buildings and subnets to a single physical backbone connection point. Coincidentally, the devices providing the existing service provide multiple interfaces. ITS could modify the existing firewall service to support these existing interfaces to create a new service that maps well onto these new conditions.

2. Would this service apply or be beneficial to others at UP?

   Yes. This service would apply anywhere multiple networks home to a single physical location. Many colleges and campuses already have this network topology or will shortly with private fiber requests.

3. Would this service apply to all University locations?

   This service applies to any University location served by a 100M or 1000M Ethernet Integrated backbone connection from the PSU core.

4. What are the benefits to this service over existing offerings, or does this service provide something completely new (from a global perspective, not a single case perspective)?

   Under the existing service, the firewall is a two-port device with one interface connecting to the router and the other connecting to the local area network. A unit could place an aggregation device — a switch — in front of the firewall to combine separate local networks, but they would share a single set of firewall rules. Units desiring separate firewall rule sets for each network would require multiple firewalls. This approach consumes more University resources, both from the standpoint of the cost of the firewalls themselves and the router interfaces they use.

   Under a modified service, the firewall is a multi-port device. While one interface still provides the router connection, the others would all be available for use on the local area network with the ability to apply a separate firewall rule set to each. The University would save by not needing multiple firewall devices and by using only a single router interface.

5. From a strategic standpoint, what are the long-term benefits/drawbacks of providing the service?

   The firewall devices can support a multi-port configuration. They provide more throughput in that configuration than with a two-port configuration. However, they do not provide as much throughput as multiple standalone firewalls would. Even if this were not the case, the multi-port configuration is naturally limited by using a single router interface, as opposed to multiple router interfaces with multiple standalone firewalls.

   On the other hand, the multi-port configuration would reduce the routers processing load for any traffic between the local area networks. By definition, these devices tie together networks within an organization. As such, it is likely that much of the traffic would remain within the local networks. This traffic would not be rate limited by the router interface. The organization might see improved performance while reducing the load on the core routers.

   In addition, when used in this configuration, the firewall can only support eight subnets per interface.

6. Can the service be provided by another University group or by an outside third party?

   Any organization within Penn State is free to implement their networks in any way they desire. However, in order to have TNS maintain a network behind a firewall, the network must use the ITS Firewall Service. ITS has recently added an option to the TNS local area network Installation and Maintenance policy. The new option has made TNS support available for the LAN behind a customer’s firewall if specific criteria are met.

7. What options does the user/customer have if TNS does not provide the service?

   The customer could use an aggregation switch behind the firewall but this would not provide any firewall capability between the networks. The customer could purchase multiple firewalls which increases cost significantly. The customer could procure a multi-port firewall from another vendor. However, TNS will not provide maintenance for a network behind a customer provided firewall since it violates the concept of “contiguous maintenance.” ITS has recently added an option to the TNS local area network Installation and Maintenance policy. The new option has made TNS support available for the LAN behind a customer’s firewall if specific criteria are met.

8. What are the proposed one time, recurring and usage rates for the service, and how do they compare to other available options (assuming there are any)?

   Assuming only the existing interfaces on the firewall, the existing price structure could apply.

9. What are the operational support issues — do spares need to be carried and how many are suggested, does it use proprietary equipment, what are the delivery (lead) time issues?

   Assuming only the existing interfaces on the firewall, no additional firewall spares would be required.

10. What are the training issues for operations, ITS user training staff and user training

    Very little additional operational training would be necessary as the existing ITS Firewall Service components would be used. We would have to educate users on the additional level of complexity involved with multi-port interconnections. That is, they need to be concerned about firewall rules between ports, as well as between the local are network and the backbone.

    Because of these added rule complexities, we do not believe it is feasible to provide an equivalent of our “Basic Firewall Service.” We believe that any customer asking for the multi-port firewall service would have to get the “Custom Firewall Service” where they define the rules.

11. What are the start-up costs (including operational support and training costs) for TNS

    Startup costs would be minimal. We could start assuming that only the existing firewall interfaces would be available. If customer demand for additional interface types and numbers was sufficient, we could consider adding them in the future.

12. What are the technical issues — will technology changes make the service unnecessary in the future, is it a mature technology or prototype, has it been proven (tested) to work in the applications suggested (and what was the process for testing), what are the expectations regarding reliability, can it be applied to the existing infrastructure, etc.?

    This enhancement to the ITS Firewall Service will use the existing hardware and software which we have been using for the last four-plus years. Although ITS has not used the equipment in this way, most non-PSU deployments use the devices with multiple ports. NP&I will conduct testing of each firewall offering chosen for this service to determine expected throughput for various configurations.

13. Will new equipment be required?

    We would be willing to offer this service on any firewall we have deployed that has additional ports available. Some of the smaller, early devices only had one extra port. The remainder had two extra ports.

    • If applicable, what exactly is the proposed equipment (manufacturer and model numbers)?

      Current offerings are:

      • Nokia IP560 Base System (Large Firewall)

      • Nokia IP390 Base System (Medium Firewall)

      • Nokia IP260 Base System (Small Firewall)

    • If applicable, what is the expected life cycle of the equipment (is it stable or will it require frequent change-outs until the technology stabilizes)?

      There has been rapid evolution in the hardware platform to date. However, the vendor made these changes to bring their manufacturing processes in line with Europe’s green manufacturing laws. We believe the product line should be more stable from now on.

14. What is the projected start date for this service?

    The only efforts I believe are required to place the new service into production are:

    • Document test results showing actual performance of the existing hardware in the proposed configuration

    • Create the internal ITS pre-announcement

    • Inform TLT Training Services

    • Review TNS workflows

    • Determine rates and billing procedures — although, I would recommend the existing structure

    • Deploy an “Operational Trial.”

    • Announce the new service

    Of these, the length of the Operational Trial will largely determine when the service will be generally available. We believe this service could be offered within 90 days.

Share: Delicious | Facebook

LACP Service Proposal

Points to be Addressed in a Proposal for a New Service:

1. Why is the proposed service believed to apply to the case at hand (what is the purpose for wanting to add the service, what are the user issues, what deficiency is thought to exist)?

   The Classroom and Lab Computing (CLC) group within Teaching and Learning with Technology (TLT) has a requirement to periodically re-image all of the classroom and lab computers. So that this does not interfere with the operation of the classrooms and labs, CLC performs this operation while the students are away during session break. As the university has moved to increase the utilization of its on campus facilities, it has continued to shorten the time when there are no students on campus. Currently, the time is short enough that the gigabit link provided by the Integrated Backbone (IB) to the CLC central servers does not have the capacity to transfer the amount of data needed in the time available.

   While we do provide a 10 Gigabit Ethernet service that provides more capacity, the technology involved would require a prohibitively expensive wholesale infrastructure replacement for CLC in order to solve a problem that only occurs for about a week a few times a year.

   By providing a backbone service that uses IEEE 802.3ad Link Aggregation Control Protocol (LACP) we can bind together either two or three standard gigabit interfaces into a single logical channel providing additional capacity using the existing CLC infrastructure.

2. Would this service apply or be beneficial to others at UP?

   This service would be beneficial to any organization within Penn State with bandwidth requirements that exceed 1 Gbps but do not merit the cost of a ten-fold increase.

3. Would this service apply to all University locations?

   This service would apply to all University locations where we currently provide gigabit Ethernet backbone service. We will not provide this service for connections to the redundant router.

4. What are the benefits to this service over existing offerings, or does this service provide something completely new (from a global perspective, not a single case perspective)?

   This service provides an incremental bandwidth improvement over the existing choices of 1 Gbps or 10 Gbps. The technology required to support 10 Gigabit Ethernet is relatively new and expensive. The technology required to support link aggregation is well established and is likely already available in the currently deployed infrastructure.

5. From a strategic standpoint, what are the long-term benefits/drawbacks of providing the service?

   The strategic benefits of providing this service are mainly in the area of improved resource utilization. At first it might seem that this proposal would consume additional router interfaces. On closer inspection we would find that any customer in this situation probably already has multiple backbone interfaces in an effort to distribute the load of their application, typically with reduced efficiency. Binding those interfaces using LACP allows us to get greater application efficiency using the same physical resources.

   The situation is reversed when moving the customer to 10 Gigabit Ethernet. Currently, router blades supporting 10 Gigabit Ethernet are expensive and low density. Each one consumes a chassis slot that could be used for other, higher density applications. While the 10 Gigabit Ethernet service is valuable for those that have a genuine need, we should preserve the scarce resource for them, and not use it for applications that only occasionally need more than one gigabit.

6. Can the service be provided by another University group or by an outside third party?

   Only TNS can provide this service since it involves the method for connecting to the Integrated Backbone.

7. What options does the user/customer have if TNS does not provide the service?

   They can impact the use of their service, or they can undertake to re-architect their infrastructure and find corresponding budget resources.

8. What are the proposed one time, recurring and usage rates for the service, and how do they compare to other available options (assuming there are any)?

   A customer that currently has the Gigabit Ethernet Integrated Backbone Service pays a one-time fee of $1,000 and no monthly fee.

   If their bandwidth requirements exceed one gigabit, they can upgrade to our 5 Gigabit Ethernet Integrated Backbone Service — using a 10-gigabit physical Ethernet that we throttle to 5 gigabits. In this case, the customer pays TNS a one-time fee of $6,000 and a monthly fee of $375.

   There are also infrastructure costs involved, as equipment to support 10-gigabit Ethernet is relatively new. In the case of CLC, they currently use HP 2848 switches to terminate the backbones in question. The equivalent switch with 10-gigabit capability is the HP 3500yl-48. The CDW cost for this switch, equipped to accept 10-gigabit Ethernet is $8,718.98.

   So, in this example, the cost difference for CLC to move from an existing gigabit to a new 5-gigabit service is on the order of $15,000 one-time and $375 per month.

   On the other hand, using LACP, the existing switches can already accept additional gigabit Ethernet connections bound to form a single backbone connection. No more hardware is necessary than if the customer had simply purchased a second backbone connection — either for the customer or TNS.

   IPv4 space is actually conserved over simply buying a second backbone connection, since in the LACP case we only assign one subnet and the protocol takes care of distributing the traffic between the links.

   There may be an argument that the Network Operations Center may need training in order to respond to customer issues regarding LACP backbone connections, simply because they are different. However, the LACP protocol is well established and provides a level of resiliency not available with a single connection.

   We would propose $1,000 per backbone router interface one-time, and $75 for equipment certification (performed by the customer with TNS supervision), plus $50 per month to cover the need for ongoing TNS training for the NOC and test engineers (see 10, below).

9. What are the operational support issues — do spares need to be carried and how many are suggested, does it use proprietary equipment, what are the delivery (lead) time issues?

   No spares are required as no new, unique, or proprietary equipment forms a part of this service.

10. What are the training issues for operations, ITS user training staff and user training

    The NOC will need training in order to properly diagnose customer issues. Within MRTG, each physical interface appears, as it normally would. In addition, a new virtual interface representing all of the traffic on the bound interfaces appears.

    Also, since this service requires more customer involvement in terms of configuration required beyond the service demark, we would suggest a “certification lab” be established where a customer could bring their device in order to ensure interoperability and proper configuration of their device before installation. This would consist of a few interfaces on a test router with canned interface configurations and equivalent test data and expected results on the network data generator/analyzer (SmartBits) along with a written procedure to follow. The customer would be expected to perform the certification under the supervision of TNS personnel. Training for those supervising would be necessary.

11. What are the start-up costs (including operational support and training costs) for TNS

    NSG and NOC training as well as the creation of the certification lab and training of its support personnel are necessary at start-up.

12. What are the technical issues — will technology changes make the service unnecessary in the future, is it a mature technology or prototype, has it been proven (tested) to work in the applications suggested (and what was the process for testing), what are the expectations regarding reliability, can it be applied to the existing infrastructure, etc.?

    This service requires additional configuration capability on the part of the customer. The requirement for the customer to pass equipment certification addresses this.

    Eventually, gigabit Ethernet interfaces will fall out of fashion, replaced by ubiquitous 10 Gigabit Ethernet and TNS will end support for the service. Before we reach that point, we will encounter customers who need an incremental improvement over the 10 Gigabit service and we will extend this one to use the new technology.

    There will be a need for this service as long as our customers are using Ethernet and some of them require incremental increases in bandwidth rather than exponential ones.

    TNS already has undertaken to convert from SONET to WAN Ethernet from our inter-campus network provider in part because it offers smaller bandwidth increments that offer more attractive pricing.

    LACP is a mature technology. It was defined in the IEEE 802.3 Ethernet standard as IEEE 802.3ad in March 2000. TNS has experience with similar technology that provided 2 Gigabit trunks for the core network at Penn State and for combining multiple T1 circuits for off campus facilities.

    Once properly configured, this service should be more resilient than alternative methods, since the remaining link continues to carry all traffic should the other link fail.

    This service will work well with the existing infrastructure.

13. Will new equipment be required?

    No new equipment is required.

    • If applicable, what exactly is the proposed equipment (manufacturer and model numbers)?

      N/A.

    • If applicable, what is the expected life cycle of the equipment (is it stable or will it require frequent change-outs until the technology stabilizes)?

      N/A.

14. What is the projected start date for this service?

    In order to satisfy the needs of the trial customer, we would like to have the trial in place by August 2, 2007.

Share: Delicious | Facebook

New Service Proposals

Here in TNS, we have a procedure for proposing new services that involves answering a set of questions and submitting them to the unit Directors for their consideration. It is a useful exercise because it makes you really think about what you are doing. Phil Coolick got the idea to post them to our blogs and I thought that seemed like a good idea, so I'll be putting up some for stuff we are working on shortly. Feel free to comment.

Share: Delicious | Facebook

Basic Ethernet Switch Replacement Requirements

I mentioned in the last TCP/IP Meeting that we have started to look for replacements for our aging Ethernet switches for the TNS LAN Service. We sent out a Request for Information (RFI) asking what devices could satisfy the following requirements. We sent the RFI to the nine vendors that Gartner placed in the Magic Quadrant for Campus LAN, which is an interesting read. They are (alphabetically):

• 3Com Corporation
• Alcatel-Lucent
• Cisco Systems
• Enterasys Networks
• Extreme Networks
• Force10 Networks
• Foundry Networks
• Hewlett-Packard
• Nortel Networks

Here is the text of the RFI as we sent it out.

Background

The purpose of this document is to outline the requirements of new devices to replace our existing Basic Ethernet Switch family. Currently there are many such devices spread across our Statewide Campus Network in the form of HP ProCurve 4000M (J4121A) and 3Com 4400 and 4900 family devices (3C17203, 3C17204, 3C17205, 3C17210, 3C17700, and 3C17701).

Currently, the Basic Ethernet Switch provides 10/100 and 100/1000 copper user ports and connects the Penn State Integrated Backbone via 100BASE-FX or 1000BASE-LX. We aggregate switches within a telecommunications room using 100BASE-TX or 1000BASE-T to provide the required number of user ports. We also connect switches between telecommunications rooms within a building using 100BASE-FX or 1000BASE-LX.

Taking into account potential future growth, upgrades in services, and the need for additional user bandwidth, the new Basic Ethernet Switch must meet the following listed requirements.

The general requirements below apply to all applications for the Basic Ethernet Switch. Afterwards, specific application requirements are given for specific applications of the switch.

General Requirements

Availability and Suitability

• AS1. Currently shipping to customers
• AS2. All of the following features currently available in shipping product
• AS3. Does not require the use of proprietary mechanisms, where an IEEE, IETF, or Internet RFC standards based mechanism is currently available

Configuration and Management

• CM1. Stores configuration settings in non-volatile memory
• CM2. Allows transfer of configuration settings to another device
• CM3. Can use ASCII file to transfer the configuration settings
• CM4. Can reload an edited ASCII configuration file to make configuration changes
• CM5. Manageable locally using console access
• CM6. Manageable remotely using SSHv2, SNMP, or HTTPS
• CM7. Provides configurable security methods for all management methods
• CM9. Provides an interface for SNMP management, version 2c or higher
• CM10. Uses standard MIB, or proprietary MIB is provided
• CM11. Allows configuration of all settings without using proprietary software
• CM12. Provides mechanism to upgrade firmware
• CM13. Uses IGMP to control multicast traffic

Monitoring

• MN1. Generates SNMP traps
• MN2. Generate syslog messages
• MN3. Date and time stamps syslog messages
• MN4. Uses either NTP or SNTP to set and maintain time
• MN5. Supports network monitoring via RMON
• MN6. Can mirror a port to another
• MN7. Propagates framing errors to the mirror port
• MN8. Mirrors port traffic at line rate
• MN9. Differentiates between mirror port inflows and outflows
• MN10. Alerts the monitoring port or log record if mirror packets are dropped

Security

• SC1. Does not forward unicast packets not destined for an individual port
• SC2. Does not forward packets to a port before learning the MAC address of the attached device
• SC3. Can remotely disable and enable individual ports
• SC4. Can continue to operate when ports are placed in the loopback condition (pin 1 to pin 3 and pin 2 to pin 6)
• SC5. Does not degrade to hub operation under ARP flood

Other Standards

• OS1. Supports IEEE 802.1Q VLANs
• OS2. Supports at least 8 VLANs per port
• OS3. Supports IEEE 802.1AB Link Layer Discovery Protocol

Interface Options and Specifications

• IO1. Passes IPv4 unicast packets at full line rate
• IO2. Passes IPv4 multicast packets at full line rate
• IO3. Passes IPv6 unicast packets at full line rate
• IO4. Passes IPv6 multicast packets at full line rate
• IO5. Passes frames as small as 64 bytes at full line rate
• IO6. Passes all frames without loss
• IO7. Supports STP
• IO6. Ports auto-negotiate
• IO7. Individual ports settable to 10 Mbps half duplex
• IO8. Individual ports settable to 100 Mbps full duplex
• IO9. Individual ports settable to 1000 Mbps full duplex
• IO10. Provides a backplane that is non-blocking at full port capacity and with port-level interconnects running at full line rate.
• IO11. Passes jumbo frames as large as 9200 bytes at full line rate

Physical Characteristics

• PC1. A 19” rack-mountable version is available
• PC2. Port connectors provided on the front panel

Environmental

• EN1. Operates in temperatures between 32 and 120°F 104°F
• EN2. Operates in humidity up to 90% non-condensing humidity

Failure Rates

• FR1. Has an MTBF no less than 100,000 hours

Specific Application Requirements

Administrative Edge Switch

The Administrative Edge switch provides network connectivity for trusted users. These networks may also support associated file servers, printers, or other network devices.

• AE1. Provides at least 32 10/100/1000BASE-T ports
• AE2. Provides at least 2 100BASE-FX ports
• AE3. Provides at least 2 1000BASE-LX ports

Administrative Aggregation Switch

The Administrative Aggregation switch is used to aggregate Administrative Edge switches within or between telecommunication rooms.

• AA1. Provides at least 6 100BASE-FX ports
• AA2. Provides at least 6 1000BASE-LX ports
• AA3. Provides at least 1 10GBASE-LR port

VoIP Edge Switch

The VoIP Edge Switch provides network connectivity for VoIP handsets on our dedicated VoIP network.

• VE1. Provides at least 24 10/100BASE-T ports
• VE2. Provides at least 2 100BASE-FX ports
• VE3. Provides at least 2 1000BASE-LX ports
• VE4. Blocks forwarding of Cisco Discovery Protocol (CDP) packets
• VE5. Provides both IEEE 802.3af and Cisco Inline Power (CIP) to each port based on the requirements of the detected media endpoint
• VE6. Allows an endpoint MAC address to be associated with each port such that only traffic from that device is accepted
• VE7. Supports TIA-1057 Link Layer Discovery Protocol for Media Endpoint Devices

VoIP Aggregation Switch

The VoIP Aggregation Switch is used to aggregate VoIP Edge networks between buildings.

• VA1. Provides at least 16 100BASE-FX ports
• VA2. Provides at least 16 1000BASE-LX ports

VCoIP Edge Switch

The VCoIP Edge Switch provides network connectivity for videoconferencing devices connected to our dedicated VCoIP network.

• VC1. Provides at least 4 100BASE-TX ports
• VC2. Provides at least 1 1000BASE-LX port

Residence Hall Edge Switch

The Residence Hall Edge Switch provides network connectivity to students in residence halls.

• RE1. Provides at least 32 10/100BASE-T ports
• RE2. Allows an endpoint MAC address to be associated with each port such that only traffic from that device is accepted
• RE3. Allows an endpoint IP address to be associated with each port such that only traffic from that device is accepted
• RE4. Provides at least 1 100BASE-FX port
• RE5. Provides at least 1 1000BASE-LX port

Wireless Edge Switch

The Wireless Edge Switch provides network connectivity for wireless access point devices on our dedicated wireless network.

• WE1. Provides at least 24 100BASE-TX ports
• WE2. Provides at least 1 100BASE-FX port
• WE3. Provides at least 1 1000BASE-LX port
• WE4. Provides IEEE 802.3af power

Share: Delicious | Facebook

Meeting a Deadline

Freelance Switch has a list of what it calls 14 Essential Tips for Meeting a Deadline. While I would say that most of them are obvious, most people still do not follow them. Here are the steps, the article has more detail for each:

1. Care about deadlines.

2. Keep a list of projects & deadlines.

3. Communicate a clear deadline.

4. Work in a cushion.

5. Have a clear outcome.

6. Break down the project.

7. Focus on the first step.

8. Block off adequate time.

9. Have a start and complete date for each step.

10. Communicate with each step.

11. Don’t overcommit.

12. Learn from mistakes.

13. Stay up late.

14. Negotiate and meet a second deadline.

Share: Delicious | Facebook

Intro to PM: System Requirements Specification, Part I: Definitions

What is a system? A system is an interdependent group of people, objects, or procedures constituted to achieve a defined objective or some operational role by performing specified functions.¹

What is a requirement? A requirement is something a system must do. It is a condition or capability a user needs in order to solve a problem or achieve an objective.

What is system requirement specification? It is a process that produces a set of requirements that, when realized, will satisfy an expressed need. It provides a description of what a system’s customers expect it to do for them. It is a way of converting raw customer requirements into well-formed and organized ones. It is a method to provide a “black-box” description of what a system should do, in terms of its interactions or interfaces with its external environment.

What does the environment of a system include? A system’s environment includes all of the things that influence the system. These fall into categories like:

• Political
• Market
• Industry Standards
• Internal Policies
• Cultural
• Organizational
• Physical

Does system requirements specification show how to build the system? No. System requirement specification does not result in a set of instructions. We use it to ensure communication between the technical community and agreement on what the system must do to achieve its goals. During design and development, we use it to determine the requirements of the various parts we determine the system must have. We use it to develop test plans. We use it to verify the system operation when we believe we are done.

References

1. Software Engineering Standards Committee of the IEEE Computer Society, ‘IEEE Guide for Developing System Requirements Specifications’, IEEE Std 1233 (1998) <http://ieeexplore.ieee.org/iel4/5982/16016/00741940.pdf> [accessed Tuesday, August 23, 2007] ↩

Share: Delicious | Facebook

Why Oracle Calendar Sucks: Reason #237

Share: Delicious | Facebook

Introduction to Program Management: Operational Concept Development

Operational Concept Development is one of the earliest steps of system development. Whether it is a new system, or an existing one that you are thinking of modifying, there are certain things that you need to know before you get too far. In fact, the simple act of asking the questions can sometimes solve the problem. So sit down, talk with your customer, and talk about the system — “it” — until you can say you know the answers to these questions.¹

A picture is worth a thousand words, and while it might take many words to answer these questions, it really might only take a few words and a some well drawn pictures.

It is good for you to know the answers to these questions, but if you write them down, you can share them with others and refer back to them as the project progresses.

1. What is it called? We need to be able to talk about the system. We work on a lot of systems. In order to know that we are talking about this one, we need a unique, memorable name.

2. What is its purpose? This is the proverbial 10,000-foot view. We are really looking for an elevator statement here.

3. What documentation about it exists? If the customer has already given the subject some thought, you owe it to them to do your homework and not waste their time regurgitating information that already exists.

4. What is its history? If the system is new, how did the idea for it arise? If it already exists, why do we have the system? When did we get it? Has it changed before? If so, why did it change before? Is the system ingrained in the culture or politics of some organization?

5. Who are the stakeholders? Identify the developers, operators, maintainers, managers, payers, users, and so on.

6. Where is it? Or, if it is a new system, where do we want it to be?

7. What are the characteristics of its operational environment? The circumstances, objects, and conditions surrounding it. Technical, political, commercial, cultural, organizational, and physical influences as well as standards and policies that govern what a system must do or how it will do it. Identify facilities, equipment, hardware, software, personnel, and procedures used with it. Be as detailed as necessary to give an understanding of the numbers, versions, capacity, and so on, of the operational environment.

8. What are its external interfaces? It must get inputs from somewhere and provide outputs to somewhere. What are they and what do they look like?

9. What functional capabilities does it have? What can you do with it?

10. What performance capabilities does it have? Speed, throughput, volume, frequency, and so on.

11. When is it used? Describe the scenarios under which a user would decide to use the system.

12. What procedures are involved in making it work? Even an autonomous system interacts with people at some point. Procedures involve interacting with people. What are they?

13. What are its major components? If it is a new system, you will want to take the answer to this question with a grain of salt. It may be convenient for the customer to explain their concept as the interaction of certain parts, but ultimately what is important is whether the system does what it should, not whether it has certain components inside. Leave defining the internal behavior — the interaction of the components — of a new system should until design time.

14. How do its components interconnect? As with the major components, for a new system, this is only a communications aid.

15. How is it supported? Some systems are vendor supported, dedicated staff supports others, and some have no support at all. Unsupported systems are actually user supported, since they are the ones that have to make it work when it breaks. The system support model will place constraints on your implementation.

16. What has happened that we want to change it? Whether it is a new system or an existing one, some trigger event resulted in the identification of the need for the system or the change. What was that trigger?

17. What changes do we want to make to it? For an existing system, you have just gotten an idea of what it encompasses. At this point, you picture either a working system or a broken one. If it is broken, you are going to talk about changing it. If it is working, you are going to talk about adding to it.

18. Which changes to it are essential? Any time you talk with the customer you should let them fully express themselves about what they are thinking. However, you need to be clear on which things are essential and which are not.

19. Which changes to it are desirable? Just below essential changes are ones that are desirable.

20. What is the priority ranking of the changes to it that are desirable? If there is more than one desirable change, you will need to know which is higher priority so you will know where to concentrate your efforts.

21. Which changes to it are optional? Ranking below desirable changes are optional changes.

22. What is the priority ranking of the changes to it that are optional? If there is more than one optional change, you will need to know which is higher priority so you will know where to concentrate your efforts.

23. What changes to it have already been considered and dismissed and why were they dismissed? In order to understand how to move ahead it is sometimes helpful to understand the logic behind what the customer may have already looked at and decided not to do.

24. What assumed constraints are involved in the changes to it? If the customer is aware of preexisting constraints — performance, physical, political, cultural, schedule — you had best know what they are up front.

25. How do the answers to questions 7–15 change because of the changes to it? Assuming the system already exists, whatever changes you make to the system itself may have an impact outside the system in terms of new external interfaces, new support mechanisms, and so on.

26. How do the changes to it address the reason, given in answer to question 16, for wanting the changes? This is a sanity check. If you get this far and you cannot explain how the suggested changes address the identified need then you need to have a serious chat with your customer. Better to have that chat now than after months of development and dollars spent on a system that does not address the need.

27. What disadvantages or limitations does it have after the change? Now that you have a sanity check, this gives you a reality check. All systems are limited. It is best to understand those limitations going in, rather than being surprised by them at then end.

References

1. Software Engineering Standards Committee of the IEEE Computer Society, ‘IEEE Guide for Information Technology — System Definition — Concept of Operations (ConOps) Document’, IEEE Std 1362 (1998) <http://ieeexplore.ieee.org/iel4/6166/16486/00761853.pdf> [accessed Tuesday, August 21, 2007] ↩

Share: Delicious | Facebook

The system works as designed.

Last Friday Jeff Kuhns asked rhetorically, “Is IT out of touch?” I would like to respond, in all seriousness, with another rhetorical question: “Who is this IT of which you speak?”

My training is in engineering and so I look at most things — be they natural phenomena, manufactured devices, or organizations of people — as systems. They have a purpose, they have parts, and they have capabilities. Things go in, the system finagles with them, and things go out the other side. So, naturally for me, when I hear the question, “Is IT out of touch?” I respond by translating it into direction thusly: “There is a system — call it IT. Is the system producing the desired output?”

To do that I have to know what the system was designed to do. I have to know what input we are giving the system, what its capacity is, and what the expected result is. Having designed many systems before, I find it likely that the correct answer to the question is, “The system works as designed.”

I am not trying to make excuses here. I am making a call to action.

You see, I think we have to look at the system we have here — IT at Penn State, that is — and see what it is made of, what its current capabilities are, and whether it does what we want it to. I am specifically not talking about technology here. I am talking about the people and the processes. If there are things that work — areas where the system gives us the desired result — we should use those parts for our benefit. If there are parts that provide a result other than the desired result, we should try to fix those areas. If we cannot provide some particular desired result then we need to think about designing a new part of the system that can address that.

In order to do any of this, we need to know the role of the parts of the system. If the system is IT at Penn State, then ITS as an organization is only part of that system. It might be reasonable to extend Jeff’s question specifically to ITS. That is, “Is ITS out of touch?” Then to answer that, we have to know what the role of ITS is within the system of IT at Penn State.

With IT at Penn State, we have the unique situation of being both centralized and distributed. To me, this is both obvious and the way it should be. There is an old joke, probably started by garage mechanics — when there were garage mechanics — it goes like this: “Quick, cheap, good. Pick any two.” Companies that only have central IT don’t get anything quick and ones that only have distributed can’t take the time to really make it good. Cheap? I do not know about cheap. Anyway, with both central and distributed, Penn State can get both Good and Quick! However, we can only achieve this if we manage the system properly. To do that, we have to understand the role of each group.

To me, the role of the distributed IT groups is to be small, nimble, and close to the customer. They can quickly respond to requests from customers and get them the solutions they need. They do not need to be concerned with whether a given solution scales to the entire population of the University. They do not need to consider whether a group 150 miles away can support it. They do not need to fit it into the priorities of an organization that is otherwise addressing the strategic objectives of the University overall.

In contrast, I see the role of the central IT group as being large, stable, and representative of the University as a whole. They can take the time to consider how to make a solution scale to satisfy the needs of 150,000 users at 24 campuses spread across the state. They can develop procedures to allow diverse groups to request, receive, and pay for the solutions. They can develop processes and provide staffing to monitor and support the solutions wherever in the state they happen to be deployed. Specifically, the role of central IT is two-fold: a) to do the heavy lifting where it is not reasonable to expect a distributed group to provide a solution because of the size or the goal involved, and b) to provide the 80% solution when many distributed groups end up providing the same solution to their customers.

Given that, if you were to ask me that second question — “Is ITS out of touch?” — I would have to proudly say, “Yes, and that is how it should be.” The system works as designed.

To continue, if we find that the system as designed — this system of people — is not providing the desired result, then we must analyze the system to determine whether the system is not working properly, or whether the system is simply not designed to produce the missing result.

The system might be broken in several obvious ways. Not that it is, but they are worth exploring.

It might be that there is a misunderstanding of the roles of the various parts of the system. Some parts might be expecting inputs from other parts that do not provide them. Alternatively, some parts may not provide something because they believe another part is already providing it. These are what you might call wiring problems. Improved communication can help to address these issues. Clearly defined roles, clearly communicated throughout the community should help define who does what and for whom.

Alternatively, it might simply be that nobody designed the system to provide the missing result. In this case, there are two possible paths forward. Either, modify part of the existing system — or create a new part — to address the missing solution. Alternatively, accept that the system cannot address all possible solutions and that sometimes it is best if customers use their own solutions — that is, work around IT — where it is appropriate to do so.

We have a good system that works as designed. It can probably do more. It can probably do what it does better. However, we should be careful not to attempt to change it to be everything to everyone, lest we end up with it being nothing to anyone.

Share: Delicious | Facebook

Introduction to Program Management: The System Development Life Cycle

There are many theories on how best to manage the development of a system. Many revolve around the idea of a system development life cycle. The analogy being that a system is conceived, is born, grows up, gets a job, and eventually dies.

There are more formulations of the system development life cycle than there are chili recipes. However, they all share a common set of activities.

I break the activities down as follows:

• Inception — Some people call this a “kick off.” I used to call it “initiation,” until somebody pointed out to me that at an institute of higher learning with an active Greek community, that term has other connotations. Regardless of what you call it, it starts with the moment when a business need or opportunity is identified, documented, approved, and a champion is appointed to pursue it.

• Operational Concept Development — This activity gives the customer an opportunity to describe and document their need without getting mired in technicalities that can be dealt with later. This is where you’ll see flowery terms like “reliable” or “easy to use.” You might also see suggestions for ways to implement the solution, but these are only suggestions. Use them to explore concerns about solution strategies, looking for design constraints. In a case where the effort is a modification to an existing system, this is an opportunity to make up for poor existing documentation and establish a baseline for it.

• Program Management (PM) Planning — Once you have a good idea what the need is, you have to think about how it impacts what you are already doing in terms of development. Does it fit with your group’s objectives? When is it needed? Is there sufficient manpower available to adequately address the expected activity? Does the group have the necessary technical resources? Does it have the necessary skill set?

• Analysis — System Requirements Specification — In this activity you identify the raw “black box” requirements — interface, functional, data, performance, security, maintainability, and so on — and from them you build “well-formed” requirements that describe capabilities the system should have and the conditions and constraints that apply to them. At the end of the activity you should be able to present an organized set of requirements that if implemented, should satisfy the identified need.

• Design (not what you think it is) — In the design activity, you look inside the black box for the first time. You come up with a plan to implement the requirements. You identify and document the components inside the box, how they interconnect, and what each has to do.

• Development — Once you know what you need inside the box, you need to figure out how you are going to provide each of those components. You’ll decide which components you are going to build and that you’ll buy, and then you’ll build and buy. At the end of this activity you should have a bunch of components ready to put together for the first time.

• Integration and Test — This is where you roll up your sleeves and put it all together, make it work, and show that it meets its requirements.

• Implementation — Once you have shown your system meets its requirements you can build as many as you need.

• Operations and Maintenance — Working systems almost always need to be watched and occasionally nudged to keep them working. This is where you do that.

• Evaluation — We would all like to think we get everything right the first time, but that never actually happens. While a system is in operation, you should evaluate whether and how it addresses the real needs of its users. If there are shortcomings, you should consider starting on a revision of, or a replacement for the system.

• Disposition — All good things come to an end. Eventually the business need will go away, or be solved in a different way that makes the system obsolete. This is where you clean up the flotsam and jetsam of the life cycle.

Update: Typically a Manufacturing phase would follow Development and precede Integration and Test. However, I believe it unlikely that anyone at Penn State will do any manufacturing as part of a system development, so I have ignored it for the purposes of this discussion.

Share: Delicious | Facebook

Avis au Public

Faire de la bonne cuisine demande un certain temps. Si on vous fait attendre, c’est pour mieux vous servir, et vous plaire.

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.

Share: Delicious | Facebook

Supremely Misguided

The Tao tells us that frustration causes all of humanity’s problems and that frustration is “wanting things to be other than the way they are.”

When I started with ITS¹ five years ago I attended the ITS New Employee Orientation. As the various units explained what they did, the number that provided network services surprised me. Why would so many groups duplicate the services of the one that hired me? I realized that “network” means different things to different people.

To some it means mail. To some it means the Web. To some it means Angel. To some it means authentication. To some it means file systems. Some differentiate at the ISO layer, others within the application, still others by operating system. This can cause problems when that VIP says, “the network is slow today.”

To me, network means transport — moving IP packets from one place to another as quickly and as confidently as possible. No more. No less. To me, the definition of “Networking” in “Telecommunications and Networking Services” is unambiguous. Unfortunately, some of the people who expect us to provide services do not share that understanding and this can lead to frustration.

Some people have valid reasons for doing things on a network that I consider anti-transport. Those things are an abomination to people that do transport and asking us to provide them is a recipe for disaster. It is supremely misguided to think otherwise. Would you go into a restaurant run by an orthodox Hindu and expect a great steak? They might offer one because the market demands it, but the wise patron will stick to the vegetarian dishes.

People who need our services fall into two categories: those who want generic transport and those who have a specific application need. It turns out that the service we provide may be useful to people in the first category. Some people play the lottery and win. These people have good Karma. As for people in the second category, well…

My group specializes in transport. The three engineers on my team and I know diddly-squat about your application. Do you know why? There are around 150,000 of you. If we spent all of our time on applications, we would spend about two man-minutes per year on yours. Is that what you think your application deserves — two minutes of consideration per year? If not, then you should not be asking us to support it. Trust me, you want us spending our time on transport. You can have the best network application in the world and without transport it is worth bupkis.

If you have an application on your network that needs something, you have a problem. You may think that asking us to provide that something sounds like a good idea. Think again. Perhaps you need to rethink your application. If you convince yourself that you need it, you may need to hire or subcontract for the expertise that you need. I do not know. However, if you want to solve your problem, you have to start by recognizing the way things are. Otherwise, you will find frustration.

---

1. Actually I started in Network Engineering, which is part of the Network Planning and Integration group in Telecommunications and Networking Service, which is a unit of ITS. Network Engineering no longer exists. I am currently the manager of Network Development Engineering. Did you notice the emphasis on “network” in all of that? I thought you did. ↩

Share: Delicious | Facebook

Missing the Target

I spent the last week in Anaheim, California at the Networkers at Cisco Live conference. The closing keynote was presented by John Cleese. He explained that he believed that the reason “why they would hire an elderly English comedian to address a group of technical types of astonishingly high IQ” was because they wanted him to play the role of court jester. He would be able to say things that were true, but too offensive for polite conversation, that the audience would feel obliged to laugh at, lest they loose face. This would let him use humor to get across information that would help them to learn about themselves, but which could easily have offended them.

After a suitable amount of offensive satire, he told a story.

There, now I hope I’ve been sufficiently offensive, so now I can make my contribution to this “geek fest” by telling you why I’ve always been just crazy for guided missiles.

Even as a very small child, these lovely creatures enchanted me far more than stories of catatonic princesses and talking vermin. Probably, because the very first nursery story that my mother ever read me was called “Gordon the Guided Missile.” And this is why the guided missile found this very, very special, very warm place in my heart.

You see, Gordon sets off in pursuit of his target and immediately sends out a signal to discover if he is on course to hit that target. The signal comes back, “No, you’re not on course, Gordon. Change it up a bit and slightly to the left.” And Gordon changes course, as instructed, and then he sends out another signal, “Am I on course now?” And back comes the answer, “No. Adjust your course down a bit and slightly further to the left.” And so he adjusts his course again. And, conscientious little fellow that he is, he sends out another request, “How am I doing now?” And back comes the answer, “Gordon, you’ve still got it wrong. Down more and a foot to the right.”

And the guided missile, its rationality and persistence a lesson to us all, goes on and on, making mistakes, and on and on listening for feedback, and on and on correcting its behavior, until it blows up the nasty enemy thing. And then we applaud Gordon.

And some critic says, “Well, he made hundreds of mistakes, didn’t he?”

Yes, but that didn’t matter did it? Because all of his mistakes were corrected, and so Gordon succeeded in avoiding the one mistake that really matters: missing the target.

— John Cleese, Thursday, July 26, 2007, Anaheim, California

My takeaway from this is that communication — explaining what you have in mind, asking for feedback, and listening to what others have to say — even if it turns out that you are wrong — is much better than not achieving your objective because you didn’t find out you were wrong until it was too late to do anything about it.

Share: Delicious | Facebook