If you’ve seen any of the USAC training for eRate, you know it says schools shouldn’t submit 470s that require specific manufacturers or part numbers, but should instead provide a list technical requirements, or list a specific part number with an “or equivalent” statement. The problem with that “or equivalent” statement is that each competing provider may interpret the equivalent features differently, since there’s not parity across all features between manufacturer products. Those differences in certain features can cause drastic variances in the cost of the solution proposed to you.
Challenges of an RFP based on specified device models
For example, let’s pretend you write your RFP for an ACME Networking switch model 4248 or equivalent. That ACME 4248 switch may be a 48-port 10/100/1000 PoE switch with full dynamic routing capabilities, redundant power supplies, and options for add-on services like PIM.
If the model you specified is outdated, or if the respondent is going to offer an equivalent option from a different manufacturer, there are several ways your needs might be interpreted. Some equivalent options for switches are matched on the form factor (1U-stack vs chassis), or on the port speeds and PoE requirements. Other times they’ll match the routing capabilities or fabric speed. From switch-to-switch, there won’t be a direct match of these features, so finding a different model that matches your specified model may be difficult. The result is that you’ll receive several quoted equivalent switches which meet some or most of the requirements, and/or you may receive quoted equivalent switches that match all the requirements but results in extreme over-specification and cost.
Here’s a sample comparison table showing a specified model with “or equivalent” and 3 switches quoted as being comparable. In this example, every one of the equivalent switches (1, 2 and 3) would meet the school’s real requirements, but none of them match all features of the specified model (ACME 4248).
Example showing 3 quoted comparable switches, all meet requirements but none match specified model
|Model||ACME 4248||MFR-X 3208||MFR-Y 5048||MFR-Z 8070|
|Form factor||1U stacking||Any up to 7U||?1U stacking||x4U chassis||×6U chassis|
|Routing||Dynamic routing||Basic inter-VLAN routing and static routing||xInter-VLAN routing only||?Dynamic routing||?Dynamic routing|
|Ports||48-port Gig PoE||44 ports Gig PoE
4 SFP+ 10GbE ports
|?48-port Gig PoE
?4 SFP+ 10GbE ports
|x72-port Gig PoE+
|?144-port Gig PoE
|Power||600W, fully redundant internal||Minimum n+1 redundant||x400W, external power module||x1500W, n+1 redundant||?1800W, n+1 redundancy|
? = matches specified model, x = does not match specified model
Specifying the devices by required features will yield more accurate options and better pricing. Let’s take a look at this from the requirements side and explore what our real needs may be, and how they could be represented.
Exploring needs and requirements
Here’s two different scenarios of what you may actually need.
- You need a basic layer-2 edge switch for classrooms: In this case, the ACME 4248 and anything equivalent are overkill. Your real needs are for a layer 2 switch with 10/100/1000 PoE, and you want a mix of 24 and 48 ports. By specifying a model with features well in excess of your needs, you’ll likely pay 2x to 3x more than you needed to.
- You need all the routing add-on features for a core switch: In this case, you actually do need all the routing features the ACME 4248 has, including dynamic routing, PIM and OSPF. However, those weren’t specified explicitly as required features, and your RFP responses include switches that don’t support advanced layer 3 routing functions. You choose based on price, but your selection won’t support 5 of the 8 functions you needed.
With both of these scenarios, the result is you end up with solutions that may be partially equivalent to features of the ACME 4248, but neither fits the requirements of your school. You’ve either over-spent or under-specified and likely have hardware that just won’t meet your needs.
Defining devices by required features or uses
If instead we specify RFPs based on our needs and anticipated uses, it gives your respondents a better chance at quoting devices that will best fit your environment. It may look something like this example.
|1||24||Small classroom switches
|2||16||Large classroom switches
|3||1||Main routing switch
Specifying the features you need in your eRate RFP (or any RFP) will ensure the respondents are quoting viable options that meet your feature requirements and use cases. Your responses will be more accurate, and in the end you’ll spend less using this method!