Addendum No. 1 to RFP #6-B143-P-00143-00.doc

Court Atkinson Procurement Specialist Financial Management and Procurement Services (FMPS) Argonne National Laboratory

9700 South Cass Avenue, Bldg. 201

Lemont, IL 60439

630-252-3388 atkinson@anl.gov

May 19, 2026

TO ALL OFFERORS:

Subject:

ALCF HPSS Disk Cache Request for Proposal (RFP) No. 6-B143-P-00143-00 Addendum No. One (1) Attached herewith for your information and use in preparing your proposal for subject project is Addendum No. 1.

Kindly acknowledge receipt of this Addendum by signing and returning one (1) copy of this letter to atkinson@anl.gov.

Sincerely, Court Atkinson Procurement Specialist

Argonne National Laboratory FMPS

Receipt Acknowledged:

Company:

By:

Addendum No. One (1)

TO

REQUEST FOR PROPOSAL (RFP) 6-B143-P-00143-00

FOR

ALCF HPSS Disk Cache Date of Addendum: May 19, 2026 This addendum is being issued to modify the subject RFP as follows:

I. Extension of Proposal Response Submission Deadline The proposal response submission deadline is hereby extended to 4:30 p.m. CST on Friday, June 05, 2026.

II. Amendment to Enclosure No. 2 – Statement of Work Enclosure No. 2 – Statement of Work is hereby amended as follows:

1. Page 5, Article 4 - Requirements, Sections 4.3 [TR] Performance, the second sentence is revised to read as follows:

“If HDD, the storage system should support a minimum aggregate throughput of 90GB/s and 105K IOPS. Block device will sustain ~200MB/s IO.”

III. Amendment to Enclosure No. 4 – Evaluation Criteria

Enclosure No. 4 – Evaluation Criteria is hereby amended as follows:

1. Page 3, Appendix 1 – Technical Criteria, table entry row 15, the Criteria description is revised to read as follows:

“If HDD based storage system supports minimum aggregate throughput of 90 GB per second minimum 105K IOPS and approximately 200 MB per second per block device.”

IV. Clarifications and Offeror Questions

Please refer to Appendix A – Clarifications and Offeror Questions, attached hereto and incorporated herein, for a list of clarifications and responses to Offeror questions.

Appendix A – Clarifications and Offeror Questions

Procurement/Contractual/Schedule Q: Can Argonne provide its anticipated timeframe for source selection and award following the proposal due date, as well as any target delivery, installation, or acceptance dates for the HPSS disk cache replacement? In addition, given current supply chain constraints, will Argonne permit structured pricing assumptions or price adjustment mechanisms during the 120-day proposal validity period?

Argonne’s objective is to complete the evaluation and make award as soon as reasonably possible after receipt of proposals. However, the time required for evaluation and award will depend on the number and complexity of proposals received, as well as the need to address any clarifications, complete the procurement file, finalize award documentation, and issue the award.

The 120-day proposal acceptance period stated in the RFP has been established to provide sufficient time for Argonne to complete this process. Offerors should not interpret that period as indicating that award will occur near the end of the 120 days; Argonne intends to proceed as expeditiously as practicable.

With respect to schedule, Argonne’s objective is delivery, installation, and acceptance as soon as possible following award. Offerors should therefore propose their earliest achievable delivery schedule in their proposals.

Due to program needs, the latest acceptable delivery date is September 1, 2026.

With respect to pricing, proposals are expected to remain firm for the full 120-day validity period identified in the RFP. Argonne is seeking firm fixed pricing for that period. Accordingly, structured pricing assumptions, escalation provisions, or price adjustment mechanisms applicable during the 120-day proposal validity period are not requested and may be viewed unfavorably.

Q: Given the requirement for an installation plan 90 days before the target installation date and a jointly developed Acceptance Test Plan 60 days before delivery, do you have a preferred sequence or calendar milestones we should reference in our Management Plan response?

These are post-award coordination requirements tied to the final mutually agreed project schedule, not independent schedule delays.

Q: Can you share whether the Laboratory expects to fund this acquisition with FY26 or FY27 funds, and whether there are any key internal funding deadlines we should be aware of that could influence delivery or acceptance schedules?

Adequate funding is available for this acquisition, and Argonne is not aware of any funding-related deadlines that would impose additional delivery or acceptance constraints beyond those stated in the solicitation.

Q: Can you confirm whether the resulting award will be placed directly under the enclosed draft purchase order (Enclosure No. 2), or via a federal contract vehicle (e.g., SEWP, GSA), and whether you anticipate any changes to the contractual vehicle as currently drafted?

Argonne anticipates that any resulting award will utilize the draft purchase order structure included in the RFP. However, if the successful proposal is submitted through GSA, ICPT, or another federal contract vehicle authorized for Argonne’s use, Argonne may issue the award through that vehicle. In such case, the award documentation (i.e., purchase or delivery order document) would be revised as appropriate to reference the applicable contract vehicle while retaining the other applicable terms, documentation, appendices, and Statement of Work, as incorporated by Argonne. Argonne does not otherwise anticipate material changes to the contractual vehicle as currently drafted.

Q: Will Argonne contract directly with the VAR only, or is there interest in or preference for direct contracts with OEMs for certain elements (e.g., maintenance) backed by our integration and services? Will multiple awards be considered?

Argonne intends to make a single award to one entity, whether that entity is a VAR or an OEM. Argonne does not intend to separately contract with an OEM for certain elements of the requirement while contracting with another entity for other elements.

Q: If we propose as a VAR with one or more OEMs, how would you prefer we delineate responsibilities for warranty, support SLAs, on site parts cache management, and escalation in our Technical and Business/Management Proposals?

The prime Offeror will remain fully responsible to Argonne for performance of all contract requirements, including management of its subcontractors and partners (i.e., OEMs and otherwise) in providing the required items/services.

Q: Will partial acceptance be considered for individual deliverables (e.g., hardware delivery, installation, configuration), or is acceptance expected only upon full system completion?

Argonne does not intend to perform partial acceptance. Successful completion of the mutually developed Acceptance Test Plan (ATP) will warrant formal system acceptance and permit the vendor to invoice for payment.

Proposal Evaluation Q: Are there particular technical criteria in Appendix 1 (e.g., performance, reliability, maintenance/support) that you anticipate will be especially discriminating among offers, beyond what is already reflected in the weighting?

No additional weighting or undisclosed discriminators will be applied beyond those stated in the solicitation.

Q: Can Argonne clarify whether the evaluation will follow a best value tradeoff approach where technical merit can outweigh cost, or if solutions must first meet defined technical acceptability thresholds before cost becomes the primary discriminator?

As further described in Enclosure No. 4, Evaluation Criteria, proposals will be evaluated using a best value tradeoff approach, under which technical merit may outweigh cost. However, proposed solutions must first meet the requirements set forth in Enclosure No. 4, Evaluation Criteria, Appendix 1 – Technical Criteria, with at least a Marginal adjectival rating. Any proposal that fails to meet one or more stated criteria will be considered unacceptable and therefore ineligible for award.

For proposals determined to be technically acceptable, total evaluated price will be assessed in conjunction with the relative merits of the technical proposals to determine whether the benefits of a higher-rated proposal justify any associated price premium. Notwithstanding the foregoing, a proposal may be excluded from consideration if its pricing cannot be adequately explained or is determined not to be fair and reasonable.

Q: Within the best value framework where Technical is more important than Price, can you provide any additional guidance on how you will consider lifecycle cost versus initial acquisition cost (e.g., support over 5+1 years, power/cooling footprint)?

Price will be evaluated in accordance with Enclosure No. 4, Section V, Price Criteria.

Q: Can you confirm whether offering additional Target Requirements (TR/TO) beyond the minimum Mandatory Requirements (MR/MO) will be explicitly recognized in the evaluation, and, if so, how you would like these enhancements documented in our Technical Proposal?

Yes. As reflected in the Statement of Work and Evaluation Criteria, Argonne’s evaluation will consider the extent to which proposed solutions address Target Requirements and Target Options. Offerors should clearly identify any proposed features, capabilities, or enhancements that satisfy or exceed those target requirements and describe them in sufficient detail to demonstrate how the proposed solution meets or exceeds the applicable criteria.

Q: For the financial statements requested in Part II, Section A, will you accept consolidated financials from the OEM supplemented by summary financial information for us as the VAR, or do you require full statements from each contracting entity?

The financial information required under Part II, Section A applies to the prime Offeror, as that entity will be responsible for performance of the contract requirements. Accordingly, the prime Offeror should submit its financial statements and any supporting information necessary for Argonne to assess its financial condition and capability.

Terms Q: For commercial terms in ANL 71 COM and the Low Risk On Site Supplemental Conditions, are there particular clauses you consider non-negotiable, versus areas where you have historically accepted reasonable commercial exceptions from OEMs or VARs?

The Laboratory will evaluate all requested exceptions on a case-by-case basis. Reasonable requests may be considered, subject to review by Argonne legal counsel and other appropriate stakeholders. However, a large number of exceptions, or one or more significant exceptions that do not provide a benefit to the Laboratory, may result in the proposal being rejected as unacceptable.

Technical Q: How do you define IOPS?

As a standard performance metric for input/output operations per second. It’s used to measure how many times a device can read or write data per second. Higher IOPS typically means better performance.

Q: What calculations are you using to determine 3.2M IOPS to Disk?

3.2M IOPS is the advertised performance metric for our currently installed disk cache storage appliance but was likely not achieved with an HDD-only solution. Estimated IOPS for the HDD-only solution is 105K IOPS.

Q: How many for Read vs Write?

Cache reads and writes are roughly 50/50 since files are written to the disk cache by users then read from cache during migration to tape. The daily rate varies greatly depending on user activity. The expected read/write IOPS ratio is 1.5:1- 2:1.

Q: 140GB’s throughput In + Out?

Yes. Real-world performance vs theoretical maximum.

Q: Are you using a customer caching algorithm?

No, we are not.

Q: For monitoring integration, you list LDMS, Check MK/Nagios, TimescaleDB, ElasticSearch, and a preference for structured metrics. Are there any specific APIs, data formats, or existing integrations you have found especially effective with current vendors that we should align with?

Generally, JSON, XML, CVS or OLTP are acceptable. REST API and possibly a telemetry API.

Q: What version of HPSS is currently deployed at ALCF, and what version will be in use when the new disk cache is deployed?

We currently have version 10.3-u16 deployed. Minor version release updates are applied as they become available.

Q: What HPSS data mover software version and configuration is currently in use? Are there any custom modifications or specific dependencies on block device presentation?

Version 10.3-u16 is installed. No custom modifications or dependencies.

Q: Would ALCF consider an alternative technical approach that exceeds performance and cost requirements but deviates from the specified block storage architecture (e.g., high-performance parallel NFS with pNFS/RDMA)?

Since HPSS is basically emulating tape on the disk cache it is unlikely to be compatible. That said, if you can prove that it will work, we would be interested in seeing it.

Q: What is the current network topology for the data mover connections and are there any planned upgrades? Specifically: - Current Ethernet speeds, switch models, router models in use (100GbE, 200GbE, 400GbE) - InfiniBand fabric details (if currently used) - Fibre Channel fabric details (if currently used) Data mover network connectivity is over 200GbE with plans to upgrade to 400GbE. Storage connectivity is directly over EDR Infiniband.

Q: Can you provide details about the current disk cache system being replaced (vendor, model, configuration)? What aspects worked well, and what challenges should be addressed?

The existing disk cache is a DDN SFA18K with 10 HDD disk enclosures providing 9PB of usable capacity. It is directly connected to 16 data mover hosts over EDR Infiniband. Each data mover host has access to every disk in the storage system. The SFA18K does not readily provide performance data which would be nice to have.

Q: Section 5.4 requires on-site parts cache. For software-defined solutions on commodity hardware, would on-site stocking agreements with hardware partners satisfy this requirement?

Yes, that should be fine.

Q: Workload characterization: Can you share the read/write ratio(s) assumed when deriving the stated IOPS and throughput requirements (e.g., 100% read, 70/30 read/write, 50/50)?

Cache reads and writes are roughly 50/50 since files are written to the disk cache by users then read from cache during migration to tape.

Q: Workload characterization: Are these ratios expected to be constant, or do they vary by use case (e.g., ingest vs. recall vs. internal HPSS migration)?

Since IO is largely user driven it is unpredictable. A file that is written to cache will be migrated to tape after 5 minutes. Recalled files, unless residing in the disk cache are written to the disk cache from tape before being restored to the filesystem.

Q: Block size assumptions: What block size(s) were used to calculate the IOPS and GB/s targets (e.g., 4 KB, 64 KB, 256 KB, 1 MB)?

The 90GB/s and 3.2M IOPS is the advertised performance for our currently installed disk cache storage appliance and was reportedly achieved with a 4KB block size. It was likely not achieved with an HDD-only solution. Estimated IOPS for the HDD-only solution is 105K IOPS.

Q: Block size assumptions: Do you expect a single dominant block size or a mix (e.g., small-block metadata + large-block data transfers)? If mixed, can you provide approximate percentages?

4K block size is a safe assumption.

Q: Access pattern details: Are the performance figures based on sequential, random, or a mix of access patterns?

Random

Q: Access pattern details: For sequential workloads, what typical transfer sizes (per stream) should we assume?

Since the archive is user driven, transfer sizes are generally unpredictable.

Q: Access pattern details: For random workloads, is there a target latency range we should design to?

No

Q: Per-device expectations: The document references ~500 MB/s per block device (SSD) and ~200 MB/s per block device (HDD). What block size and read/write mix underlie those per-device numbers?

4K block size. Sequential read/write.

Q: Per-device expectations: Are those per-device numbers sustained expectations or peak values under ideal conditions?

Peak values under ideal conditions

Q: Concurrency and stream behavior: For the “16 parallel data streams achieving 90% of 400 GbE line rate” requirement, what block size and read/write mix per stream should we assume?

4K block size. 50/50 read/write mix

Q: Concurrency and stream behavior: Are those streams independent HPSS movers, or multiple streams per mover host?

Independent movers.

Q: Test methodology / reference: If these targets were derived from an existing environment or benchmark, can you share:

· the tool(s) used (e.g., IOR, FIO, custom HPSS tests), and

· any public or internal reference results that reflect the desired behavior (including block sizes, queue depths, and read/write ratios)?

NA

Q: Operational separation vs. physical separation: Is your primary requirement that there be a clear logical/operational separation between - (1) The storage system’s management/control plane, and (2) The HPSS data mover hosts and processes, regardless of whether these run on the same or separate physical hardware?

We prefer to apply our own configuration management on data mover hosts whether those are virtual machines or physical servers. That said, some level of management control over VMs by the storage system is anticipated.

Q: 3.2 Storage Presentation: Are all LUNS presented to all data movers?

Yes, they are.

Q: 4.7 Facility: Does the data center have existing Racks, PDU etc for the ALCF Archive Storage Disk Cache? If it does, please share the manufacturer and model numbers. If not, please provide the floor space available and if this space is adjacent in the same row We are assuming that the solution will reside in a single rack that will need to be provided.

Q: What, if any, compression ratio is Argonne receiving on the block storage being requested?

NA

Q: Can you provide the following:

· read/write mix for HPSS disk cache ingest, migration-to-tape, and recall

· sequential vs random I/O split

· typical and maximum I/O size

· average, median, and largest file/object size Roughly 50/50 read/write mix

50/50 sequential vs random IO split

IO size metrics are not readily available, but it’s safe to say most of the IO requests are less than 1GB

Without scanning the entire archive file size is not readily available.

Q: What is the connectivity that your tape system requires?

The tape tier is not in the scope of this proposal. That said, tape drives are FC connected to data mover hosts.

Q: How is the RFP defining “Block device count” nodes, LUNs?

Nodes in this case refer to data move hosts, either virtual machines or physical servers. LUNS in this case refer to disk volumes presented to data mover hosts. I don’t see the phrase “Block device count” in the RFP.

Q: How much rack space is allocated for this procurement?

We are assuming that the solution will reside in a single rack that will need to be provided.

Q: Architecture and Storage Presentation (SOW 4.1 / 4.1.1): Which RHEL major version(s) must movers support at delivery and across the 5+1 year term?

RHEL9 is currently installed. RHEL10 will be an option.

Q: Capacity and Performance (SOW 4.2 / 4.3)

· Confirm 10 PiB is base-2, post-RAID/erasure, excluding hot spares, and that dedupe/compression may not be counted toward usable capacity.

· For HDD targets (90 GB/s, 3.2M IOPS, 200 MB/s per device), what block size and read/write mix define the IOPS measurement?

· Is the 16 parallel streams at 90% of 400GbE line-rate measured per mover, per array port, or system-aggregate?

· What benchmark tooling (i.e., IOR, fio, vendor native) will be used during ATP, so performance commitments align with acceptance testing?

Confirmed 10PiB is base-2, post-RAID/erasure, excluding hot spares, and that dedupe/compression may not be counted toward usable capacity.

The 90GB/s and 3.2M IOPS is the advertised performance for our currently installed disk cache storage appliance and was reportedly achieved with a 4KB block size and random read/write. It was not likely achieved with an HDD-only solution.

Estimated IOPS for the HDD-only solution is 105K IOPS.

System aggregate

Iperf, dd, vendor native

Q: Connectivity (SOW 3.1 / 4.6): If FC is proposed, will ALCF provide the SAN fabric, or must switching be included in the offeror BOM?

FC fabric and switching would need to be included in the BOM.

Q: Monitoring and Integration (SOW 3.3 / 4.4). Which API surfaces (REST/JSON, SNMPv3, Redfish, streaming telemetry) are required versus preferred for integration with LDMS, Nagios, TimescaleDB, and Elastic?

None are required, those listed are desired.

Q: Facility (SOW 4.7)

· Confirm 415Vac 3PNE with IEC60309 is the intended rack feed; will ALCF provide any 480Vac-to-415Vac transformation, or must the offeror include it?

· Confirm the 600 kW power budget applies solely to this disk cache system and is not shared with other archive infrastructure.

· Are there any rack-weight limits that would exceed the 1,500 lb concentrated / 700 lb/ft² uniform floor rating in TCS-DC?

Confirmed rack feed. Offeror should provide the appropriate rack PDU

Assume shared

No

Q: Maintenance and Support (SOW 5)

· Under 9x5 NBD with a one-hour response, does the SLA measure remote engineer engagement or on-site arrival?

· Will ALCF provide secured space for the on-site parts cache?

The 9x5 NBD with one hour response SLA would be remote engineering engagement.

ALCF will provide a secure space for the on-site parts cache.

Q: 3.2M IOPs of what nature? Please specify the exact nature of the HDD IOPs test: random vs sequential, R/W ratio, block size (e.g. 4K/8K/64K), queue depth, and workload profile.

3.2M IOPS is the advertised performance metric for our currently installed disk cache storage appliance and was reportedly achieved with a 4KB block size and random read/write. It was not likely achieved with an HDD-only solution. Estimated IOPS for the HDD-only solution is 105K IOPS.

Q: Is there a requirement in addition to the 10PB of storage for other requirements, such as a database or analytics specific to HPSS? If so, is that a requirement of this RFP?

No.

Q: Can Argonne define the specific criteria and process for system acceptance, including any required performance validation or testing procedures?

Validation of the storage would likely be tested from the data mover hosts using dd or similar utility.

Q: Can Argonne clarify the expected support model for critical and system-impacting issues, including target response times, escalation procedures, and expected resolution or workaround timelines? Additionally, should offerors assume that support beyond the stated 9x5 Next Business Day service level (e.g., 24x7 coverage) is required or preferred for production HPC operations?

Initial response time from support engineers should be within 1 hour of reporting an issue. If a resolution cannot be achieved in a reasonable timeframe, or progress is not being made escalation procedures should be readily available and easy to execute. If on-site personnel is unable to repair failed hardware from the parts cache the offeror will be required to provide on-site support by the next business day. Optional 12x7 support should be proposed.

Q: Is remote support acceptable for initial triage and issue resolution, or is on-site support expected for all incidents?

Remote support is acceptable for initial triage and issue resolution.

Q: 3.2 Storage Presentation - What storage data transport do you anticipate between the Linux data movers and the storage system (e.g., Ethernet, RoCE, InfiniBand, FC, SAS)?

Infiniband is the transport used for the current storage, but we are not opposed to other viable transports.

Q: 4.1.1 [TR] Accessibility - What block protocols do you expect? NVMe-oF, iSCSI, FC, SAS?

No specific expectation but SAS is generally acceptable.

Q: 4.1.1 [TR] Accessibility - Do you expect Offerors to integrate with existing facility fabrics (switching/IB core already present), or should the proposal include any required switching to achieve target connectivity?

If direct connectivity is not an option, switching should be included in the proposal.

Q: 4.2 [MR] Capacity - Do you have a preference for all-flash, all-HDD, or hybrid SSD+HDD media for the disk cache tier?

We prefer a solution that is both cost effective and performant.

Q: 4.2 [MR] Capacity - Is a hybrid SSD+HDD solution acceptable? If so, do you expect data placement/tiering to be managed by the block storage subsystem or by HPSS/mover-side policy (e.g., separate raw LUN pools per tier with HPSS controlling placement)?

Hybrid SSD+HDD is acceptable as long as it is managed by the storage system.

Q: 4.2 [MR] Capacity - If hybrid is acceptable, do you have an expected SSD/HDD split (by usable capacity and/or by performance), or should Offerors propose the ratio?

Offeror should propose the ratio.

Q: 4.3 [TR] Performance - A single High Performance HDD gets around 120 iops. 3.2M IOPS would require on the order of 26k drives. Can you confirm whether the 3.2M IOPS target is correct for an HDD-only solution?

3.2M IOPS is the advertised performance metric for our currently installed disk cache storage appliance but was likely not achieved with an HDD-only solution. Estimated IOPS for the HDD-only solution is 105K IOPS.

Q: 4.3 [TR] Performance - For the published throughput/IOPS targets, what workload assumptions should be used (block size(s), read/write mix, sequential vs random access pattern, queue depth, and concurrency)?

4K block size, 50/50 read/write mix, 50/50 sequential vs random access mix

Q: 4.3 [TR] Performance - Where should performance be measured for evaluation/acceptance (at the storage interface, at the Linux data mover hosts, or end-to-end through HPSS workflows)?

The storage interface.

Q: 4.3 [TR] Performance - The SOW references ~200 MB/s per block device (HDD) and ~500 MB/s per block device (SSD). Does ‘per block device’ mean per raw LUN presented to HPSS, and is this assumed to be single-stream per LUN or multi-stream?

Yes, per raw LUN. Not necessarily a single stream.

Q: 4.3 [TR] Performance - The SOW target calls for a minimum of 16 parallel data streams to achieve 90% of line rate on a 400GbE link. Is this target per mover, per storage port, or aggregate across the complete solution?

Aggregate across the complete solution.

Q: Can ALCF share historical performance data or usage patterns from the existing disk cache to help size and optimize the replacement system?

Neither HPSS nor the disk cache provide historical performance data. HPSS provides utilization metrics such as these. The HPSS purge policy maintains a consistent amount of free space in the disk cache.

U. S. Department of Energy laboratory managed by UChicago Argonne, LLC