Telecom WAN RFI - Questions and Answers - Sheet1 (1).pdf

# question answer

While reading the RFI document I saw that the current CSN is an MPLS-based enterprise network. I was curious if there was an incumbent contract for Internet Access Sourcing or if the State runs these services internally?

The State of Colorado does not run these internet access services internally. There are multiple commercial incumbent contracts currently in place. These services were established via the previous procurement, Invitation for Bid (IFB) #2021000166, which resulted in multiple permissive price agreements with commercial carriers to deliver Layer 2 Wide Area Network (WAN) connectivity and dedicated internet access across the state. This current RFI (2026-044) serves as formal market research to prepare for the upcoming re-compete and modernization of these expiring agreements

Although this project is currently in the RFI stage, I was wondering if the State had an estimated contract value for a potential contract that would be awarded should this project move past the RFI stage?

The State is not disclosing an estimated contract value or internal budgetary parameters at this time. this Request for Information (RFI) is strictly an informational market research mechanism, not a formal source selection method. A core objective of this RFI is to gather voluntary industry cost models and technical data to help the Governor's Office of Information Technology (OIT) appropriately define functional requirements and establish an accurate, market-informed budget for any subsequent formal solicitation.

Does the State have a mechanism to pay NRC costs and or Construction costs for circuits requested?

The State is currently evaluating how different commercial carriers amortize large-scale network expansion and construction costs. Please use your RFI submission to outline your standard public-sector mechanisms for handling these fees—specifically whether your business model favors up-front Non- Recurring Costs (NRC) or rolling them into the Monthly Recurring Charge (MRC) over a 3-to-5-year term.

How will the State evaluate tradeoffs between simplicity (flat bandwidth tiers) and cost accuracy (zonal pricing)?

The State is utilizing this Request for Information (RFI) phase precisely to gather industry feedback and cost visibility regarding both flat bandwidth tiers and zonal pricing models. A primary objective is to analyze how each structure impacts market-driven competitiveness, OIT's administrative level of effort, and long-term cost predictability.

To ensure maximum cost accuracy, the State requires visibility into the underlying architecture of the proposed cost structures—specifically concerning "last-mile" loop delivery. The State recognizes that carriers frequently lease last-mile circuits from third-party incumbent providers, which can introduce hidden variable fees and distort comparative pricing metrics. Proponents are strongly encouraged to submit data, risk-mitigation recommendations, and voluntary pricing examples for both methodologies.

Additionally, the State requests that respondents provide explicit guidance on the following:

Last-Mile Transparency: Detail whether your standard flat-tier or zonal pricing options bundles third-party loop leasing fees into a unified rate, or if last-mile access charges are isolated as a variable pass-through component.

solicitation Cost Normalization: Provide specific recommendations on how the State should structure its future Request for Proposals (solicitation) pricing tables to cleanly normalize last-mile loop lease variables across disparate geographical zones.

Should the State transition to a formal solicitation, the State will establish a standardized pricing evaluation matrix and baseline scenario. This will incorporate the market feedback captured during this RFI to ensure all submitted cost proposals are evaluated on a completely clear, equitable, and "apples-to-apples" basis.

How will off-net or third-party LEC costs be normalized across vendors to ensure fair evaluation?

The State is utilizing this Request for Information (RFI) phase precisely to gather industry data, cost visibility, and operational feedback regarding how to structure our equitable cost normalization model in the upcoming solicitation. A primary objective of this market research is to determine which mechanism— such as a standardized "Market Basket" network scenario, localized pricing zones, or fixed access loop placeholders—will best optimize transparency and ensure a fair "apples-to-apples" comparison.

Proponents are strongly encouraged to submit explicit recommendations, logistical data, and structural best practices from similar public sector footprints outlining how third-party Local Exchange Carrier (LEC) and "last-mile" variables can be isolated and evaluated with the lowest amount of cost risk to the State.

Will pricing submissions be evaluated on total cost of ownership (TCO) over term vs static MRC comparisons?

The State has not yet finalized the structural cost evaluation mechanics for the upcoming formal solicitation. A primary objective of this Request for Information (RFI) phase is to leverage market research to help make that determination.

The State is currently evaluating the administrative efficiency of a static Monthly Recurring Charge (MRC) structure against the comprehensive risk-mitigation benefits of a Cost of Ownership Life Cycle Analysis

(TCO).

Call to Action for Respondents: Proponents are highly encouraged to utilize their RFI submissions to recommend pricing methodologies, share sample template frameworks, and outline the pros and cons of both MRC and TCO models as they apply to large-scale telecom footprints. Specifically, please highlight how each model impacts long-term cost predictability and fair market competition.

Does the State intend to standardize core hub connectivity into fixed infrastructure components?

Will core hub requirements include diversity mandates (physical path, carrier diversity, etc.)?

The State has not made final determinations regarding fixed infrastructure standardization or specific diversity mandates for the upcoming solicitation footprint. In alignment with public purchasing best practices, the primary objective of this Request for Information (RFI) phase is to gather baseline market intelligence to help make these exact structural determinations. The State is utilizing this RFI to evaluate current industry capabilities, localized carrier constraints, and optimal physical path redundancy configurations.

Call to Action for Respondents: Proponents are strongly encouraged to submit technical data, case studies, and engineering recommendations outlining how core hub connectivity and carrier redundancy can be optimized. Please explicitly highlight any regional infrastructure bottlenecks or supply-chain variables that the State should consider when drafting the final solicitation specifications to maximize full and open competition.

What level of API or system integration does the State expect for eProcurement/catalog ordering?

The State has not finalized the specific API protocols or exact catalog integration requirements (e.g., punchout vs. hosted catalogs) for the upcoming formal solicitation.

However, in accordance with Colorado Fiscal Rule 1-2, any prospective solution must possess the inherent technical capability to securely interface with the core State Financial System to ensure transaction integrity and eliminate administrative redundancies.

Call to Action for Respondents: The State is utilizing this RFI phase to identify prevailing market standards for B2B eProcurement connectivity. Respondents are highly encouraged to use their submissions to outline their standard integration frameworks. Specifically, please provide information regarding your platform's native support for standard API web services, cXML/OCI punchout catalog capabilities, and automated e-invoicing workflows, detailing how these frameworks typically minimize deployment risk and lower total cost of ownership for government entities.

Is jumbo frame (9000 MTU) a mandatory requirement or a preferred capability?

The State has not yet finalized whether jumbo frame (9000 MTU) support will be a mandatory requirement or a preferred capability in the subsequent formal solicitation. A primary objective of this Request for Information (RFI) phase is to evaluate the availability of this attribute within the current supplier marketplace.

The State is evaluating the operational value of jumbo frame capabilities against the potential impact on overall competition, cost, and infrastructure limitations.

Call to Action for Respondents: Proponents are highly encouraged to use their RFI submissions to outline the technical advantages, performance trade-offs, and cost impacts of supporting a 9000 MTU standard across a multi-site public footprint. Specifically, please clarify if mandating 9000 MTU support would restrict your organization's ability to participate in a future competitive bidding process.

What evaluation criteria will carry the most weight in the future RFP (price vs performance vs flexibility)?

Will the State favor standardized pricing models over custom optimization per location?

How will risk (e.g., rural delivery, scalability) be factored into scoring?

The State has not finalized the specific evaluation criteria weights, pricing methodologies, or risk-scoring allocations for the upcoming solicitation footprint. In alignment with public purchasing best practices, the primary purpose of this RFI phase is to gather market intelligence that will actively inform these structural and fiscal determinations.

To assist the State in optimizing the structure of the upcoming solicitation, Respondents are requested to provide feedback on the following areas within their submittals:

Weighting & Performance: Provide evidence-based recommendations on how the State should balance cost against performance and operational flexibility to secure high-performing long-term infrastructure.

Pricing Models: Detail the market standards for commercial infrastructure pricing. Specifically, outline the pros, cons, and cost-containment implications of utilizing a strictly standardized pricing model versus a custom, location-optimized matrix across a highly diverse geographic footprint.

Risk & Scalability: Provide standard industry risk-mitigation frameworks for rural delivery and multi-site scalability. Highlight specific performance metrics, milestones, or SLA baselines the State should build into its future evaluation criteria to successfully isolate and award low-risk, resilient solutions.

Should the future solution include only WAN transport and internet access services, or should it also include SD-WAN overlay, orchestration, security, implementation, and operational support?

The State has not yet finalized the definitive scope of work regarding the aggregation of transport layers and managed overlay services for the subsequent formal solicitation. A core objective of this Request for Information (RFI) phase is to evaluate the availability, market standard, and fiscal efficiency of both models within the supplier marketplace.

The State is actively evaluating the operational value of an unbundled framework (transport only) versus a fully integrated, full-stack managed solution (inclusive of SD-WAN overlay, orchestration, security, implementation, and ongoing operational support).

Call to Action for Respondents: Proponents are strongly encouraged to utilize their RFI submissions to detail the cost-benefit trade-offs, deployment timelines, and long-term risk profiles of both approaches.

Specifically, please clarify how bundling these advanced orchestration and security services affects your organization's pricing models, and identify any critical standard integration risks the State should account for if it chooses to procure transport separately.

What is the desired operational model: customer-managed, fully managed by the provider, or a shared-management model?

The State has not finalized a preferred operational or management model for the future solution. A primary objective of this Request for Information (RFI) phase is to evaluate the operational feasibility, internal resource impacts, and commercial risk-allocation of customer-managed, fully provider-managed, and shared-management frameworks.

The State is evaluating how each model balances long-term value against internal OIT contract administration overhead and system orchestration requirements.

Call to Action for Respondents: Respondents are highly encouraged to use their RFI submissions to detail the distinct boundaries of responsibility, resource requirements, and cost profiles associated with their proposed operational models. Specifically, please clarify how your recommended model optimizes service-level agreement (SLA) enforcement, minimizes transition risk, and impacts the total cost of ownership for a large-scale public entity.

How many total sites are in scope at contract start, and what is the expected growth over the contract term, including cooperative or piggybacking entities?

The State has not finalized a fixed, mandatory site-count baseline or an absolute growth curve for the initialization of this contract. A primary strategic objective of this Request for Information (RFI) phase is to actively analyze how the carrier community structures its standard, commercial volume-discount matrices.

Rather than forcing the market into a custom, static tiering model that inadvertently drives up artificial contingency pricing, the State seeks to discover where commercial operational thresholds naturally scale.

The State intends to use this data to design a highly open and competitive pricing evaluation matrix for a subsequent solicitation.

Call to Action for Respondents: Respondents are requested to provide their standard, "out-of-the-box" facility tiering brackets and detail how their pricing architectures optimize around those specific commercial profiles. Specifically, please clarify:

1. Your standard out-of-the-box classification boundaries for defining facility profiles (e.g., small remote field office vs. mid-tier branch vs. regional aggregation hub) based on standard bandwidth capacity or session metrics.

2. How your volume-discount matrices dynamically scale when additional political subdivisions or permissive cooperative purchasing entities "piggyback" onto the contract footprint over time.

3. Your standard industry recommendations on how the State should structure its upcoming RFP cost submittal forms to cleanly capture and normalize these commercial tiering brackets on an equitable, "apples-to-apples" basis.

Can the customer classify sites into standard technical profiles such as small branch, standard branch, large branch, regional hub, critical site, and data center/core site?

The State has not finalized a rigid technical profile classification for its facility footprint. A primary objective of this Request for Information (RFI) phase is to leverage market research to understand how the supplier community standardizes, bundles, and benches architectural site profiles. The State seeks to avoid an overly prescriptive framework that inadvertently limits a vendor's ability to offer creative, innovative, or cost-effective solutions tailored to the State's future-state goals.

Call to Action for Respondents: Respondents are highly encouraged to utilize their RFI responses to detail their own standard commercial profiling methodologies. Specifically, please clarify:

1. How your standard service offerings naturally map to the categories mentioned (small, standard, large branch, regional hub, critical site, and data center).

2. The specific technical boundaries, bandwidth thresholds, and equipment densities your organization uses to differentiate between these tiers.

3. How your proposed tiered profiling model optimizes total cost of ownership (TCO) and simplifies long-term contract administration for a large-scale public entity.

Which sites require dual wired connectivity, and which sites can use a single wired circuit with wireless backup?

The State has not pre-determined a static engineering design for connectivity redundancy or backup circuits across its distributed footprint. To maximize free and open competition and foster innovation, the State utilizes performance-based criteria focused on business outcomes rather than rigid technical inputs.

For the purposes of providing an equitable benchmark for your RFI submittal, Respondents should assume that the State’s distributed sites will be categorized by operational criticality, and are requested to propose their standard deployment architectures against the following functional tiers:

Tier 1: Core/Critical Sites & Data Centers: These sites require a zero-downtime, continuous operations framework. Respondents should detail how their standard resilient architectures (e.g., dual wired circuits via diverse paths/carriers, SD-WAN orchestration) meet or exceed a [e.g., 99.99%] availability uptime standard.

Tier 2: Standard/Regional Branch Sites: These facilities handle routine daily public services and administrative operations where brief, managed failover windows are acceptable. Respondents should outline their standard deployment strategies for these profiles (such as a single wired circuit backed by a secure wireless/cellular backup) and clarify the estimated recovery time during a failover event.

Tier 3: Small/Remote Sites: These low-volume or seasonal sites have flexible uptime tolerances.

Respondents are invited to propose their most cost-effective connectivity models (including standalone single wired or primary wireless/LTE options) that optimize the total cost of ownership (TCO).

Call to Action for Respondents: Please explicitly outline how your commercial pricing models, equipment sets, and SLA metrics scale across these three performance tiers, and identify any hidden risks or facility constraints the State should consider when preparing its final technical specifications.

Which site types require private transport, and which are eligible for dedicated internet access, broadband, cellular, or mixed-transport designs?

The State has not established a rigid, static technical mandate prescribing specific transport mediums (such as MPLS or private circuits) for explicit site types. In alignment with public purchasing best practices, the upcoming solicitation will be structured around performance-based outcomes, functional requirements, and security metrics rather than prescriptive inputs.

For the purposes of providing a uniform benchmark in your RFI submittal, Respondents should assume that the State’s primary evaluation lens will be based on data classification, compliance parameters, and uptime criticality. Respondents are requested to analyze scalability and outline their standard architectural recommendations across the following functional profiles:

High-Compliance / Mission-Critical Data Paths: For sites handling highly sensitive or strictly regulated data metrics (e.g., CJIS, IRS Publication 1075, HIPAA, or core data center traffic), please outline how your proposed orchestration securely manages these paths. Explicitly detail whether your design leverages private transport or implements advanced encryption fabrics over public circuits (DIA/Broadband) to meet State security thresholds.

Standard Administrative & Distributed Operations: For routine branch operations, please describe your standard commercial best practice for utilizing mixed-transport or hybrid network designs. Clarify how your solution utilizes cost-effective broadband as a primary active path while dynamically balancing workloads.

Remote / Resiliency Paths: For remote facilities or backup routing, detail your standard model for cellular (LTE/5G) integration. Clarify any bandwidth degradation limitations the State should anticipate during an active failover window.

Call to Action for Respondents: Respondents are requested to outline their standard commercial templates for these profiles and provide data demonstrating how a mixed-transport network architecture reduces initial capital expenditures and ongoing operational costs ($TCO$) without compromising regulatory compliance or network performance.

Does the customer require a phased migration model where the existing WAN and the future WAN architecture operate in parallel during transition?

The State has not finalized a mandatory migration timeline or a prescriptive parallel-operations framework for the WAN transition. A core strategic objective of this Request for Information (RFI) is to leverage market research to discover how the supplier community minimizes deployment, configuration, and transition risks for a highly distributed public footprint.

The State’s primary motivator is the absolute protection of public services and data-continuity paths. The State seeks to avoid establishing a rigid procedural rigidity that inadvertently drives up artificial "contingency pricing" or limits a vendor's ability to offer creative, innovative, or highly automated migration strategies.

Call to Action for Respondents: Respondents are highly encouraged to utilize their RFI responses to detail their standard commercial migration methodologies for large-scale public entities. Specifically, please clarify:

Your standard best practice for migrating diverse facility footprints (e.g., whether you recommend a parallel dual-WAN overlay model or a flash-cut approach by site tier).

The specific cost, schedule, and quality risks associated with operating the existing WAN and your future WAN architecture in parallel.

How your proposed migration model minimizes the internal level of effort required by OIT personnel and ensures zero disruption to mission-critical public applications.

What are the required performance targets for availability, latency, jitter, packet loss, repair time, and failover time by site class?

The State has not finalized a rigid, static matrix of prescriptive engineering targets (such as explicit millisecond latency boundaries or packet loss percentages) for specific site classes at this RFI stage. In alignment with public purchasing best practices, the upcoming solicitation will be structured around performance-based outcomes, functional requirements, and mission-criticality metrics rather than design standards.

For the purposes of providing a uniform benchmark in your RFI submittal, Respondents should assume that the State’s primary performance lens is built around application continuity, data integrity, and operational criticality. Respondents are requested to outline their standard commercial service-level tiering templates (SLAs/SLOs) that align with the following functional profiles:

Tier 1: High-Criticality / Life-Safety Operations: For sites executing continuous, mission-critical operations where any network degradation directly impacts public safety or legal compliance (e.g., continuous database replication, public safety endpoints). Please outline your standard availability, sub-second failover times, and Mean Time to Repair (MTTR) capabilities for these high-availability fabrics.

Tier 2: Core Administrative & Business Operations: For routine branch operations utilizing cloud-based applications (e.g., ERP, standard citizen-facing web portals, and office software). Please detail the standard commercial parameters for latency, jitter, and packet loss that your solution dynamically guarantees to maintain optimal application performance.

Tier 3: Remote / Low-Density / Resiliency Sites: For facilities with standard administrative needs or secondary backup routing (e.g., cellular/broadband paths). Please provide your standard performance targets and outline any bandwidth degradation limits the State should anticipate during active failover windows.

Call to Action for Respondents: Respondents are requested to provide data demonstrating how their standard software-defined architectures automatically prioritize traffic to meet these tiered profiles, and to map out the cost-versus-performance trade-offs of enforcing strict financial penalties (liquidated damages) against these targets.

Should service-level objectives be measured at the circuit level, site level, application level, or end-to-end across the WAN architecture?

The State is currently evaluating all measurement frameworks—including circuit, site, application, and end-to-end metrics—to establish the most operationally sustainable and commercially balanced framework for the upcoming formal solicitation. > As outlined in Section 1.4, the State is actively migrating the Colorado State Network (CSN) to a modern, Software-Defined Wide Area Network (SD-WAN) architecture to distribute mission-critical application traffic across over 600 remote endpoints and highly secure core data hubs. Because this is a formal market research phase , the State seeks to understand standard carrier delivery models that maximize performance while minimizing administrative tracking overhead. Call to Action for Respondents:

Respondents are requested to provide data demonstrating how their standard software-defined architectures automatically prioritize traffic to meet these tiered profiles, and to map out the cost-versus-performance trade-offs of enforcing strict financial penalties (liquidated damages) against these targets.

Please include these insights within the Technical Suitability Memorandum portion of your submittal.

What are the mission-critical applications or traffic types that require prioritization, path control, or guaranteed performance?

The State intends to leverage standard SD-WAN application-aware routing and dynamic path control to prioritize network traffic based on broad functional profiles rather than rigid, application-specific design restrictions.

Consistent with procurement best Practices, the State seeks a performance-based solution where the awarded respondent utilizes their standard architectural expertise to ensure optimal traffic steering. For the purposes of this RFI and the upcoming formal solicitation, respondents should assume the network must automatically prioritize and guarantee performance across the following high-level traffic categories:

Real-Time Interactive: Voice over IP (VoIP), unified communications (e.g., video conferencing), and real-time collaboration tools.

Mission-Critical Cloud/SaaS: Enterprise resource planning (ERP), identity management, and cloud-hosted productivity suites.

Core Infrastructure Traffic: Network management, security logging, and protocols critical to endpoint connectivity.

Standard Business/Bulk Data: General web browsing, email, large file transfers, and routine database replication.

Call to Action for Respondents: Respondents are requested to provide information in their Technical Suitability Memorandum detailing how their solution dynamically maps, identifies, and prioritizes these functional profiles. Please highlight how your platform handles sub-second path steering during transport degradation without requiring manual administrative intervention, and note if your standard solution maps to these profiles out-of-the-box.

Are voice, video, public safety, emergency response, contact center, or real-time collaboration applications considered critical traffic classes?

Yes. The State confirms that enterprise voice, video, contact center, and real-time collaboration applications are considered critical traffic classes that require strict prioritization. Furthermore, public safety and emergency response applications represent the highest-priority operational traffic distributed across the Colorado State Network (CSN).

As detailed in Section 1.4, these vital installations distribute mission-critical, high-volume applications to State employees and citizens daily. Per Section 2.6 of the RFI, the State fully expects the awarded provider’s core transport fabric to natively honor, preserve, and pass all internal State IP Quality of Service (QoS) markings without modification or header rewriting.

Call to Action for Respondents: Respondents are requested to provide data demonstrating how their standard software-defined architectures automatically prioritize traffic to meet these tiered profiles, and to map out the cost-versus-performance trade-offs of enforcing strict financial penalties (liquidated damages) against these targets. Please explicitly detail if your standard commercial offering includes pre-configured CoS queues that align with these public safety and real-time communication demands.

Where are the primary applications hosted today: state data centers, public cloud, SaaS platforms, agency-local environments, or a combination of these?

The State of Colorado operates a highly distributed, hybrid computing environment that utilizes a combination of all the hosting models listed in the inquiry.

Consistent with the performance-focused objectives of this RFI and the administrative standards set forth in the Colorado State Fiscal Rules, the State requires an enterprise SD-WAN solution capable of dynamically steering traffic across a multi-tiered, hybrid ecosystem without introducing localized processing bottlenecks. For planning and information-gathering purposes, respondents should assume the network fabric must seamlessly optimize paths between edge endpoints and the following core environments:

State-Managed Data Centers: Centralized legacy applications, core databases, and agency-specific processing systems hosted in secure, state-operated facilities.

Public Cloud Environments (IaaS/PaaS): Multi-agency operational workloads migrated to public cloud infrastructure fabrics.

Software-as-a-Service (SaaS) Platforms: Enterprise productivity suites, decentralized agency workflows, and identity management platforms consumed directly via cloud-native SaaS models.

Agency-Local Environments: Distributed field offices and regional facility perimeters requiring localized edge computing connectivity.

Call to Action for Respondents: Respondents are requested to provide information detailing how their standard software-defined architectures automatically map, secure, and differentiate path selection for Direct Internet Access (DIA) to SaaS/Public Cloud endpoints versus backhauling corporate traffic to a centralized physical data center.

Is local internet breakout required, preferred, or prohibited for specific site types or agencies?

The State does not mandate a singular internet breakout posture across all endpoints. Instead, local internet breakout requirements are tiered based on the operational and security profile of the specific agency and site type.

The State’s upcoming SD-WAN architecture must natively support dynamic, policy-based path selection to accommodate three primary operational postures:

Local Breakout Preferred/Required: For general administrative endpoints and standard branch offices heavily utilizing cloud-native SaaS platforms, local internet breakout (Direct Internet Access) is preferred to optimize application performance and minimize latency. For smaller, remote field offices operating primarily on broadband loops, local breakout is required to conserve core transport capacity.

Local Breakout Restricted/Prohibited: For highly sensitive perimeters—such as public safety nodes, correctional facilities, and agencies bound by strict federal or state data compliance mandates—local internet breakout is strictly restricted or prohibited. Traffic from these site types must be backhauled to centralized state security stacks or secure data center hubs.

Call to Action for Respondents: Respondents are requested to provide technical data demonstrating how their platforms dynamically enforce centralized security policies for preferred local breakout sites (e.g., via cloud-delivered security or embedded edge firewalls) while concurrently maintaining strict, cryptographically isolated backhaul pathways for restricted agencies on the same SD-WAN fabric.

What routing protocols must be supported at the WAN edge, and is dynamic routing integration required with existing core, data center, or agency networks?

The State of Colorado requires that the proposed WAN edge solution support standard, non-proprietary open routing protocols to ensure full interoperability across all legacy and modernized agency networks.

Dynamic routing integration with the State’s existing core networks, decentralized agency infrastructures, and centralized data centers is a mandatory functional requirement. To achieve automated path optimization, real-time failover, and any-to-any reachability, the solution must seamlessly integrate with the State's existing network topology. Proponents must demonstrate native, wire-speed support for the following open routing standards at the WAN edge:

Border Gateway Protocol (BGP): The solution must support standard BGP for dynamic exterior routing, multi-homed internet connections, and secure cloud exit path selection.

Open Shortest Path First (OSPF): The solution must support standard OSPF for interior gateway routing and local area network fabric propagation.

Static and Policy-Based Routing (PBR): The solution must support flexible static path mapping and application-aware policy routing configurations.

Call to Action for Respondents: Respondents should detail how their platforms orchestrate the translation of legacy local routing protocols (LAN) into the SD-WAN overlay routing environment. Please specify if your edge solution requires external hardware or complex routing redistribution templates to integrate with existing multi-vendor core data center environments.

Is IPv6 currently required, planned during the contract term, or only a future consideration?

The State of Colorado views native IPv6 capability as a current functional requirement for the underlying technology platform, with a phased implementation planned during the contract term.

The State’s application profile currently operates in a hybrid fashion, where core cloud infrastructure and multi-tenant SaaS environments utilize dual-stack pathways, while various localized agency networks remain on IPv4. Consequently, the enterprise SD-WAN solution must natively support dual-stack (IPv4 and IPv6) architecture within both the control and data planes from the time of deployment.

The platform must possess the capability to carry IPv6 payload traffic over IPv4 transport networks (and vice versa) without requiring supplementary edge hardware upgrades or licensing fees. While the State will manage individual agency transition timelines dynamically over the life of the contract, the edge equipment and centralized management overlay must support this lifecycle on day one.

Call to Action for Respondents: Respondents are requested to outline their platform's standard capabilities for orchestrating dual-stack fabrics. Please specify your architectural roadmap for supporting IPv6-only transition segments, including localized network address translation (NAT64/DNS64) capabilities embedded at the WAN edge.

Is multicast required across the WAN, and if so, which applications, agencies, or locations depend on it?

The State of Colorado requires that the proposed enterprise WAN solution natively support and efficiently manage multicast traffic profiles to accommodate existing agency operations, though widespread continuous utilization varies by department.

For the purpose of establishing a common baseline for this solicitation, respondents must assume that the platform must accommodate the following Current Conditions and functional requirements:

Agency Dependency Profiles: Widespread enterprise application routing relies primarily on unicast traffic.

However, specific specialized sectors—including public safety video distribution networks, real-time transportation telemetry (CDOT), and statewide agency training broadcast streams—depend on dynamic multicast routing.

Functional Overlay Capability: The solution must natively support the propagation, mapping, and management of Protocol Independent Multicast (PIM) or equivalent routing mechanisms across the SD- WAN fabric.

Path Optimization: The proposed platform must demonstrate the ability to dynamically replicate multicast streams at the edge or closest localized node to prevent unnecessary duplication of bandwidth consumption across the state's core underlay circuits.

Call to Action for Respondents: Respondents should specify how their platform orchestrates multicast traffic over a hybrid WAN underlay. Please detail any bandwidth thresholds, licensing tiers, or architectural constraints (e.g., unicast encapsulation overhead) your solution introduces when processing active multicast streams across multi-tenant state agency environments.

What segmentation model is required, such as agency segmentation, application segmentation, user-group segmentation, security-zone segmentation, or regulatory segmentation?

The State of Colorado requires a multi-dimensional, non-proprietary segmentation model capable of executing simultaneous logical isolation across multiple distinct vectors within a centralized multi-tenant framework.

Due to the diverse operational and compliance landscapes across the State's agencies, a singular segmentation methodology is insufficient. Proponents must demonstrate that their solutions can dynamically enforce isolation based on the following criteria:

Agency/Multi-Tenant Segmentation: Complete logical routing separation at the macro level to prevent cross-agency data visibility unless explicitly permitted by centralized state policy.

Regulatory Compliance Segmentation: The native capability to cryptographically or logically isolate traffic blocks subject to strict compliance oversight, including but not limited to Criminal Justice Information Services (CJIS), HIPAA, and PCI-DSS.

Application & Security-Zone Segmentation: Micro-segmentation capabilities at the WAN edge to isolate specific application profiles (e.g., centralized enterprise payroll or public-facing portal traffic) into secure zones independent of physical user locations.

Call to Action for Respondents: Respondents must detail how their centralized orchestrator manages, deploys, and scales multi-vector segmentation matrices across a multi-agency enterprise underlay.

Please specify if your platform requires secondary firewalls, unique software tier licensing, or complex routing encapsulation overrides to maintain regulatory compliance boundaries.

Should internet-bound traffic be inspected locally, centrally, through cloud-delivered security services, or through a hybrid security model?

The State of Colorado views traffic inspection architecture as an open, functional capability requirement.

The State intends to evaluate solutions that can support a flexible or hybrid deployment model based on localized agency needs, performance profiles, and bandwidth economics.

The State’s multi-agency landscape features highly diverse network nodes. Certain centralized datacenters and high-security agency headquarters may leverage centralized or localized on-premises inspection infrastructure. Conversely, distributed field offices and cloud-native agency environments are prime candidates for cloud-delivered security services (such as Secure Access Service Edge/SASE architectures) to minimize latency and eliminate unnecessary backhaul costs.

Therefore, the enterprise platform must be architecturally agnostic enough to support local breakout inspection, centralized security stacks, and cloud-delivered security layers under a single, unified orchestration plane.

Call to Action for Respondents: Respondents are requested to outline their platform's support for variable inspection models. Please provide a clear breakdown of how your architecture optimizes internet-bound traffic without degrading performance, and specify how your security framework enforces a uniform web-security and threat-protection posture across both on-premises and cloud-delivered enforcement points.

What technical integrations are required for monitoring, alerting, inventory, ITSM, SIEM, ticketing, billing validation, API access, or automated provisioning?

The State of Colorado requires a platform built on an open, extensible, and secure API architecture capable of bidirectional programmatic integration with the State’s core enterprise management systems.

The awarded solution must natively support standard integration protocols (e.g., RESTful APIs, webhooks, Syslog, and standard SNMP/NetFlow telemetry) to facilitate automated operations across the State's cross-agency IT landscape. While the formal solicitation will detail the final technical environment, respondents should assume integration compatibility with the following functional baselines:

ITSM & Ticketing Integration: The capability to automatically generate, update, and close incident tickets within the State’s centralized IT Service Management platform plane based on network alerting thresholds.

Security Operations (SIEM): Real-time event log streaming and cryptographic telemetry exporting to the State's centralized Security Information and Event Management infrastructure for compliance monitoring.

Automated Provisioning & Inventory: Exposure of comprehensive, well-documented API endpoints to allow the State's orchestration tools to dynamically discover assets and automate configuration provisioning.

Billing Validation: Native data exporting functionalities (e.g., CSV, JSON, or programmatic database views) to allow for automated reconciliation against the State's central financial accounting records.

Call to Action for Respondents: Respondents must detail their platform’s integration capabilities, including whether access to their full API library requires secondary licensing, proprietary software intermediaries, or custom middleware. Please provide examples of successful enterprise-scale integrations your platform has executed with leading ITSM and SIEM platforms in public sector environments.

What transport transparency requirements must providers disclose, including MTU limits, jumbo-frame support, QoS preservation or remarking, VLAN limits, MAC limits, protocol filtering, and multicast handling?

The State of Colorado requires comprehensive technical disclosure regarding transport transparency and operational boundaries to support a multi-agency enterprise optimization framework. The State does not mandate a singular physical transport architecture; instead, providers must explicitly define their network underlay performance metrics within the proposal forms.

To ensure an objective value and risk analysis across all competing solutions, respondents must detail their platform's native capabilities, limits, and architectural constraints across the following vectors:

MTU Limits & Jumbo-Frame Support: Disclose the maximum transmission unit (MTU) supported across the fabric. Specify if the network natively handles jumbo frames up to 9000 bytes or enforces standard 1500-byte limits including overlay encapsulation overhead.

QoS Preservation vs. Remarking: Define how the network plane processes incoming DiffServ/DSCP and Class of Service (CoS) bits. Clarify if the underlay guarantees end-to-end QoS bit preservation or if packets are subject to automated carrier remarking policies.

VLAN & MAC Sizing Limits: Disclose the maximum number of concurrent 802.1Q VLAN tags preserved across a single logical trunk, alongside active MAC address learning limits per edge endpoint before throttling occurs.

Protocol Filtering & Multicast Handling: Detail any mandatory Layer 2 or Layer 3 protocol filtering blocks (such as BPDU or link-local filtering). Outline native data plane support for Protocol Independent Multicast (PIM) and IGMP state synchronization across distributed agency endpoints.

In Section 2.7, the State identified the three sections a bidder should include in our response to this RFI. Where in these sections should bidders include responses to Sections 2.3 – 2.6?

Bidders must include their comprehensive narratives and technical disclosures for Sections 2.3 through

2.6 explicitly within Section 2 (Technical and Functional Response) of their submittal package.

To ensure a structured review, responses should be clearly indexed and follow the exact sequential order of the RFI requirements. For absolute clarity, please map the sections as follows:

RFI Section 2.1 & 2.2 (Administrative/Company Profile): Must be placed within Section 1 (Vendor Background & Administrative Overview).

RFI Sections 2.3, 2.4, 2.5, & 2.6 (Core Technical, Integration, and Transport Specifications): Must be placed entirely within Section 2 (Technical and Functional Response).

RFI Section 2.7 (Supplemental Exhibits/Appendices): Any proprietary baseline product architectures, workflows, or whitepapers supporting your technical claims must be placed within Section 3 (Supplemental Materials & Attachments).

Call to Action for Respondents: Submissions that mix technical capability statements throughout the administrative or supplemental volumes may face difficulties during the State's comparative suitability assessment. Please utilize the standard response templates provided in the RFI workbook to ensure all responses are seamlessly cross-referenced.