En el plan de entrega del item 2, establecen: a mas tardar a los 30 días hábiles contados del día
siguiente de la recepción de la orden de compra.
Al respecto, solicitamos a la convocante ampliar el plazo de entrega a 90 días hábiles considerando los tiempos de fabricacion e importacion de los equipos
En el plan de entrega del item 2, establecen: a mas tardar a los 30 días hábiles contados del día
siguiente de la recepción de la orden de compra.
Al respecto, solicitamos a la convocante ampliar el plazo de entrega a 90 días hábiles considerando los tiempos de fabricacion e importacion de los equipos
Saludos. Ajustarse al PBC, en consideracion a la necesidad institucional y al cierre de los periodos presupuestarios anuales.
12
Solicitud de Prórroga
Solicitamos respetuosamente a la convocante que se considere la posibilidad de ampliar el plazo para la presentación de ofertas por un mínimo de 10 (diez) días hábiles, de modo a garantizar una mayor calidad en las ofertas y un proceso más competitivo y beneficioso para el MTESS. Dado el nivel de complejidad técnica de los bienes requeridos incluyendo servidores, storage, switches y demás equipos informáticos, resulta indispensable contar con un plazo razonable que permita realizar un análisis detallado de las especificaciones técnicas exigidas en el PBC, a fin de garantizar el pleno cumplimiento de las condiciones establecidas y poder elaborar una oferta de calidad y competitiva en términos económicos. Este plazo adicional permitiría recibir más propuestas de fabricantes. Esto va en beneficio directo de la convocante, al ampliar el abanico de opciones viables y promover una mayor participación de oferentes en condiciones de cumplir adecuadamente con el objeto contractual.
Solicitamos respetuosamente a la convocante que se considere la posibilidad de ampliar el plazo para la presentación de ofertas por un mínimo de 10 (diez) días hábiles, de modo a garantizar una mayor calidad en las ofertas y un proceso más competitivo y beneficioso para el MTESS. Dado el nivel de complejidad técnica de los bienes requeridos incluyendo servidores, storage, switches y demás equipos informáticos, resulta indispensable contar con un plazo razonable que permita realizar un análisis detallado de las especificaciones técnicas exigidas en el PBC, a fin de garantizar el pleno cumplimiento de las condiciones establecidas y poder elaborar una oferta de calidad y competitiva en términos económicos. Este plazo adicional permitiría recibir más propuestas de fabricantes. Esto va en beneficio directo de la convocante, al ampliar el abanico de opciones viables y promover una mayor participación de oferentes en condiciones de cumplir adecuadamente con el objeto contractual.
Saludos. Se ha prorrogado los plazos. Se recuerda que debido a la necesidad institucional y los cierres anuales, no se podran otorgar mas extensiones.
13
Para el ítem 3 Servidor. Factor de forma.
Solicitan: Rackeable de 1U como máximo.
Solicitamos que puedan ser aceptados equipos con factor de forma de 2U como máximo, en lugar del límite actual impuesto de 1U. Teniendo en cuenta que la cantidad de puertos de red / Tarjeta de red, exigida en la configuración base requiere un espacio físico adicional en la mayoría de los fabricantes, lo que obliga a optar por un equipo de 2U. Permitir equipos de hasta 2U garantizará la integración adecuada de las interfaces solicitadas, manteniendo una ventilación óptima, la escalabilidad del sistema y el cumplimiento de las especificaciones técnicas establecidas por más de una marca, además es importante mencionar que esto no afecta el cumplimiento de los demás puntos y no influye en el rendimiento y/o funcionalidades requeridas, la consulta es cursada con el fin de poder flexibilizar el presente requerimiento y poder permitir la participación de marcas y modelos que cumplen con todas las especificaciones requeridas, de tal forma a no limitar con dicha exigencia establecida.
Solicitamos que puedan ser aceptados equipos con factor de forma de 2U como máximo, en lugar del límite actual impuesto de 1U. Teniendo en cuenta que la cantidad de puertos de red / Tarjeta de red, exigida en la configuración base requiere un espacio físico adicional en la mayoría de los fabricantes, lo que obliga a optar por un equipo de 2U. Permitir equipos de hasta 2U garantizará la integración adecuada de las interfaces solicitadas, manteniendo una ventilación óptima, la escalabilidad del sistema y el cumplimiento de las especificaciones técnicas establecidas por más de una marca, además es importante mencionar que esto no afecta el cumplimiento de los demás puntos y no influye en el rendimiento y/o funcionalidades requeridas, la consulta es cursada con el fin de poder flexibilizar el presente requerimiento y poder permitir la participación de marcas y modelos que cumplen con todas las especificaciones requeridas, de tal forma a no limitar con dicha exigencia establecida.
La especificación de 1U garantiza la máxima densidad de equipos por rack, un factor crucial para l a escalabilidad futura y el uso eficiente del espacio, que es un recurso costoso y finito.
En el mercado es comprobable a existencia de equipos que satisfacen sobradamente esta necesidad de puertos.
Se mantiene la especificación original de "Rackeable de 1U como máximo" sin modificación.
No es una exigencia arbitraria, sino una condición necesaria para la integración exitosa del equipo en el entorno operativo existente.
La especificación no impide la participación de múltiples fabricantes, ya que existe una amplia y competitiva oferta de switches de alto rendimiento en factor de forma 1U que cumplen con todos los requisitos técnicos detallados en el pliego. Por lo tanto, este criterio asegura el cumplimiento de las necesidades de espacio del MTESS sin sacrificar las funcionalidades, el rendimiento o la competencia entre oferentes calificados.
Por lo expuesto, se mantiene la especificación original sin modificación.
14
Para el ítem 4 Storage
Considerando que el almacenamiento es un componente crítico y que la institución debe considerar adquirir equipos con la máxima disponibilidad posible, solicitamos que la exigencia de disponibilidad mínima se eleve del 99,9999% al 100%. Es importante además tener en cuenta que cualquier interrupción, por mínima que sea, puede implicar pérdida de datos o afectación de los servicios. Establecer un requerimiento de 100% de disponibilidad fomenta la implementación de mecanismos de redundancia total y tolerancia a fallos, asegurando así la continuidad operativa sin interrupciones
Considerando que el almacenamiento es un componente crítico y que la institución debe considerar adquirir equipos con la máxima disponibilidad posible, solicitamos que la exigencia de disponibilidad mínima se eleve del 99,9999% al 100%. Es importante además tener en cuenta que cualquier interrupción, por mínima que sea, puede implicar pérdida de datos o afectación de los servicios. Establecer un requerimiento de 100% de disponibilidad fomenta la implementación de mecanismos de redundancia total y tolerancia a fallos, asegurando así la continuidad operativa sin interrupciones
Un sistema, por más redundante que sea, tiene una probabilidad estadística de falla concurrente en múltiples componentes que, aunque ínfima, es mayor a cero. Además, una métrica del 100% es imposible de medir y verificar contractualmente.
La especificación actual del 99.9999% no es una concesión, sino un estándar de la industria para los sistemas más críticos y representa un nivel de excelencia técnica llevada al extremo.
Se mantiene la especificación original de una disponibilidad mínima del 99.9999%.
Elevar la exigencia al 100% no solo es imposible, sino que introduciría una ambigüedad contractual y técnica que podría ser contraproducente, pudiendo incluso disuadir a fabricantes de primer nivel de participar al establecer una condición inalcanzable.
Por lo expuesto, se mantiene la especificación original sin modificación.
15
Para el ítem 4 Storage. Bahías
Solicitan: La caja principal debe soportar como mínimo 25 bahías de discos.
Solicitamos que puedan ser aceptados equipos con 24 bahías como mínimo, atendiendo a que la mayoría de las plataformas de almacenamiento empresarial utilizan configuraciones estándar de 24 bahías en sus chasis principales. Este ajuste permite la compatibilidad con los modelos más recientes sin comprometer la capacidad ni el rendimiento. La diferencia con lo requerido es mínima, además, esto permite una mayor participación y competitividad de oferentes y marcas, sin afectar la funcionalidad técnica requerida y garantizando incluso mayor escalabilidad a través de chasis de expansión, la consulta es cursada con el fin de poder flexibilizar el presente requerimiento y poder permitir la participación de marcas y modelos que cumplen con todas las especificaciones requeridas, de tal forma a no limitar con dicha exigencia establecida.
Solicitan: La caja principal debe soportar como mínimo 25 bahías de discos.
Solicitamos que puedan ser aceptados equipos con 24 bahías como mínimo, atendiendo a que la mayoría de las plataformas de almacenamiento empresarial utilizan configuraciones estándar de 24 bahías en sus chasis principales. Este ajuste permite la compatibilidad con los modelos más recientes sin comprometer la capacidad ni el rendimiento. La diferencia con lo requerido es mínima, además, esto permite una mayor participación y competitividad de oferentes y marcas, sin afectar la funcionalidad técnica requerida y garantizando incluso mayor escalabilidad a través de chasis de expansión, la consulta es cursada con el fin de poder flexibilizar el presente requerimiento y poder permitir la participación de marcas y modelos que cumplen con todas las especificaciones requeridas, de tal forma a no limitar con dicha exigencia establecida.
Existen múltiples fabricantes líderes que ofrecen modelos de almacenamiento All-Flash NVMe cuyo chasis principal supera las 24 bahías (ej., configuraciones de 25, 26 o más bahías), cumpliendo con este requisito sin inconvenientes
Se mantiene la especificación original de "25 bahías de discos como mínimo" en el chasis principal sin modificación.
La especificación se basa en un resultado de capacidad y diseño, no en un modelo específico.
Este requisito es técnicamente fundado y está alineado con el objetivo de adquirir una solución robusta, con capacidad de crecimiento y optimizada para el rendimiento desde el primer día. La diferencia de una bahía, aunque aparentemente pequeña, es un diferenciador en el diseño arquitectónico del sistema y en la planificación de capacidad a largo plazo.
La especificación actual garantiza que se evalúen soluciones con un nivel de consolidación y escalabilidad inicial acorde a las necesidades del datacenter del MTESS, y no restringe la competencia, ya que existe una oferta competitiva de fabricantes que pueden cumplirla.
Por lo expuesto, se mantiene la especificación original sin modificación.
16
Para el ítem 4 Storage. RAID
Solicitan: “El sistema de almacenamiento debe tener la capacidad de proveer arreglos RAID 6 y RAID 10”
Solicitamos que el requerimiento de RAID 10 sea opcional o, en su defecto, excluido. Teniendo en cuenta que, el arreglo RAID 6 proporciona un nivel superior de protección, permitiendo la falla simultánea de dos discos sin pérdida de datos, lo que lo hace más adecuado para entornos de almacenamiento empresarial actuales, el RAID 6 se alinea con los estándares ampliamente soportados por los principales fabricantes del mercado. Aunque RAID 10 en ciertos casos puede ser útil, no es indispensable y su implementación generalmente aumenta innecesariamente el costo del hardware. Establecer esta característica como opcional o excluirlo brindará una mayor flexibilidad, fomentando la competitividad entre oferentes y marcas, la consulta es cursada con el fin de poder flexibilizar el presente requerimiento y poder permitir la participación de marcas y modelos que cumplen con todas las demás especificaciones requeridas, de tal forma a no limitar con dicha exigencia establecida.
Solicitan: “El sistema de almacenamiento debe tener la capacidad de proveer arreglos RAID 6 y RAID 10”
Solicitamos que el requerimiento de RAID 10 sea opcional o, en su defecto, excluido. Teniendo en cuenta que, el arreglo RAID 6 proporciona un nivel superior de protección, permitiendo la falla simultánea de dos discos sin pérdida de datos, lo que lo hace más adecuado para entornos de almacenamiento empresarial actuales, el RAID 6 se alinea con los estándares ampliamente soportados por los principales fabricantes del mercado. Aunque RAID 10 en ciertos casos puede ser útil, no es indispensable y su implementación generalmente aumenta innecesariamente el costo del hardware. Establecer esta característica como opcional o excluirlo brindará una mayor flexibilidad, fomentando la competitividad entre oferentes y marcas, la consulta es cursada con el fin de poder flexibilizar el presente requerimiento y poder permitir la participación de marcas y modelos que cumplen con todas las demás especificaciones requeridas, de tal forma a no limitar con dicha exigencia establecida.
Se mantiene la especificación original que exige que "El sistema de almacenamiento debe tener la capacidad de proveer arreglos RAID 6 y RAID 10".
Esta exigencia es técnica y operativamente fundamental. No se trata de una preferencia, sino de un requisito de diseño para un entorno de datacenter heterogéneo como el del MTESS, donde coexisten aplicaciones sensibles a la latencia con otras prioritarias en capacidad y protección.
La capacidad de soportar ambos esquemas de RAID es un estándar en todos los sistemas de almacenamiento empresarial de gama media y alta. Por lo tanto, este requisito no limita la participación de oferentes calificados, al contrario, asegura que la solución adjudicada tenta la versatilidad y el rendimiento necesarios para soportar la gama de servicios de Tecnología del MTESS.
17
Inconsistencias del PBC
En el Pliego de Bases y Condiciones (PBC), dentro del “Plan de entrega y recepción”, se dispone que los equipos “serán entregados primeramente para su recepción provisoria… Posteriormente… deberán ser trasladados e instalados en el datacenter de la DINAPI y/o en la sede central del MTESS… a cargo del proveedor adjudicado… para su recepción definitiva”.
Sin embargo, el PBC no precisa el alcance técnico de dicha “instalación”, lo cual impide dimensionar correctamente costos, tiempos y recursos del servicio a cotizar.
Conforme a la Ley N° 7021/22, la convocante debe especificar al nivel más detallado posible los bienes y servicios a adquirir (art. 25), de manera consistente con el estudio de mercado y las condiciones técnicas del objeto, a fin de asegurar planeamiento, comparabilidad y valor por dinero.
Adicionalmente, la propia Ley incluye —dentro del concepto de “adquisiciones”— la instalación por parte del proveedor cuando corresponda, lo que refuerza la necesidad de delimitar su alcance en el PBC.
A nivel procedimental, la “aclaración” es la vía correcta para precisar contenidos sin modificar el PBC (no es adenda), por lo que solicitamos se emita la debida aclaración en el SICP, conforme a la definición y plazos vigentes.
En ese marco, solicitamos se aclare detalladamente el alcance de la “instalación” requerida, indicando expresamente:
Límites del servicio
a. ¿Se trata solo de entrega, desembalaje y conexión física básica (ubicación, energización y prueba de encendido) o incluye montaje en rack (rails, tornillería, organización de cableado, etiquetado), conexionado de red (UTP/fibra, paneles, transceivers), y puesta en servicio?
b. Para servidores: ¿incluye instalación en rack, energización por PDU, conexión a switches ToR, actualización de firmware/BIOS/ILO, configuración de RAID/arranque y stress test inicial?
c. Para storage: ¿incluye montaje, cableado (FC/iSCSI), zoning o mapeo de LUNs, configuración básica de pools/volúmenes y pruebas de rendimiento?
d. Para switches: ¿incluye montaje, alimentación dual, uplinks, configuración lógica (hostname, usuarios, NTP, SNMP, syslog, VLANs, STP, LAGs, QoS básica), hardening y carga de versión estable de software?
e. Para computadoras de escritorio: ¿solo entrega y verificación, o también imagen de SO, unión a dominio, políticas, y pruebas funcionales?
Alcance de configuración lógica y responsabilidades
a. Especifiquen hasta qué nivel de configuración de servidores/storage/switches será exigido al proveedor (p. ej., “configuración básica de fábrica vs. integración a dominio/hipervisores/aplicaciones”).
b. Indiquen si la integración con sistemas existentes (AD, virtualización, backup, monitoreo, seguridad) forma parte del alcance del proveedor o del personal TIC del MTESS, y qué insumos proveerá la convocante (IPs, máscaras, VLAN IDs, credenciales, estándares de naming, plantillas).
c. Definan criterios de aceptación por tipo de equipo (checklist de verificación, logs de pruebas, matriz de conformidad).
Condiciones de sitio y pre-requisitos
a. Confirmen si los racks, PDUs, bandejas, patch panels, transceivers, cables y etiquetado requerido serán provistos por la convocante o deben ser cotizados por el proveedor.
b. Especifiquen ventanas de trabajo, accesos a áreas restringidas (DINAPI/MTESS), normas de seguridad, y si habrá visita/inspección técnica obligatoria u opcional antes del tope de consultas (art. 41 Res. DNCP 230/25).
Documentación de entrega
a. Precisen qué documentos deben entregarse: inventario patrimonial con códigos de catálogo y atributos (cuando correspondan), reportes de pruebas, respaldos de configuración, actas de conformidad. (Res. DNCP 230/25 sobre uso de catálogo, plantillas y atributos).
Garantías y soporte
a. Indiquen si el proveedor debe dejar firmware/OS en versión recomendada y entregar plan de reversión.
b. Señalen si se exige acompañamiento post–puesta en marcha (p. ej., N días de soporte onsite/remoto) y las SLA mínimas.
Criterios de medición y aceptación
a. Establezcan los hitos (recepción provisoria en sede Perú; instalación en DINAPI/MTESS; recepción definitiva) y los requisitos de aceptación por hito.
b. Indiquen si la recepción definitiva exigirá pruebas funcionales (por tipo de equipo) y qué resultados mínimos deberán evidenciarse.
Estas precisiones son necesarias para evitar que los oferentes asuman supuestos dispares de instalación que distorsionen los precios y afecten la comparabilidad de ofertas, contrariando los deberes de especificar necesidades “al nivel más detallado posible” y de planificar con base en las características técnicas y de mercado del objeto (Ley 7021/22, arts. 25 y 26).
Asimismo, recordamos que la precisión requerida puede y debe efectuarse mediante aclaración (sin alterar el PBC), respetando los plazos tope de consultas y respuestas en el SICP.
Petitorio:
Se solicita a la Convocante publicar Aclaración en el SICP que delimite el alcance de instalación y puesta en servicio conforme a los puntos 1 al 6 supra, o, alternativamente, disponer (y difundir) una visita técnica previa al tope de consultas para relevar condiciones de sitio y emitir luego la aclaración consolidada (art. 41 Res. DNCP 230/25).
En el Pliego de Bases y Condiciones (PBC), dentro del “Plan de entrega y recepción”, se dispone que los equipos “serán entregados primeramente para su recepción provisoria… Posteriormente… deberán ser trasladados e instalados en el datacenter de la DINAPI y/o en la sede central del MTESS… a cargo del proveedor adjudicado… para su recepción definitiva”.
Sin embargo, el PBC no precisa el alcance técnico de dicha “instalación”, lo cual impide dimensionar correctamente costos, tiempos y recursos del servicio a cotizar.
Conforme a la Ley N° 7021/22, la convocante debe especificar al nivel más detallado posible los bienes y servicios a adquirir (art. 25), de manera consistente con el estudio de mercado y las condiciones técnicas del objeto, a fin de asegurar planeamiento, comparabilidad y valor por dinero.
Adicionalmente, la propia Ley incluye —dentro del concepto de “adquisiciones”— la instalación por parte del proveedor cuando corresponda, lo que refuerza la necesidad de delimitar su alcance en el PBC.
A nivel procedimental, la “aclaración” es la vía correcta para precisar contenidos sin modificar el PBC (no es adenda), por lo que solicitamos se emita la debida aclaración en el SICP, conforme a la definición y plazos vigentes.
En ese marco, solicitamos se aclare detalladamente el alcance de la “instalación” requerida, indicando expresamente:
Límites del servicio
a. ¿Se trata solo de entrega, desembalaje y conexión física básica (ubicación, energización y prueba de encendido) o incluye montaje en rack (rails, tornillería, organización de cableado, etiquetado), conexionado de red (UTP/fibra, paneles, transceivers), y puesta en servicio?
b. Para servidores: ¿incluye instalación en rack, energización por PDU, conexión a switches ToR, actualización de firmware/BIOS/ILO, configuración de RAID/arranque y stress test inicial?
c. Para storage: ¿incluye montaje, cableado (FC/iSCSI), zoning o mapeo de LUNs, configuración básica de pools/volúmenes y pruebas de rendimiento?
d. Para switches: ¿incluye montaje, alimentación dual, uplinks, configuración lógica (hostname, usuarios, NTP, SNMP, syslog, VLANs, STP, LAGs, QoS básica), hardening y carga de versión estable de software?
e. Para computadoras de escritorio: ¿solo entrega y verificación, o también imagen de SO, unión a dominio, políticas, y pruebas funcionales?
Alcance de configuración lógica y responsabilidades
a. Especifiquen hasta qué nivel de configuración de servidores/storage/switches será exigido al proveedor (p. ej., “configuración básica de fábrica vs. integración a dominio/hipervisores/aplicaciones”).
b. Indiquen si la integración con sistemas existentes (AD, virtualización, backup, monitoreo, seguridad) forma parte del alcance del proveedor o del personal TIC del MTESS, y qué insumos proveerá la convocante (IPs, máscaras, VLAN IDs, credenciales, estándares de naming, plantillas).
c. Definan criterios de aceptación por tipo de equipo (checklist de verificación, logs de pruebas, matriz de conformidad).
Condiciones de sitio y pre-requisitos
a. Confirmen si los racks, PDUs, bandejas, patch panels, transceivers, cables y etiquetado requerido serán provistos por la convocante o deben ser cotizados por el proveedor.
b. Especifiquen ventanas de trabajo, accesos a áreas restringidas (DINAPI/MTESS), normas de seguridad, y si habrá visita/inspección técnica obligatoria u opcional antes del tope de consultas (art. 41 Res. DNCP 230/25).
Documentación de entrega
a. Precisen qué documentos deben entregarse: inventario patrimonial con códigos de catálogo y atributos (cuando correspondan), reportes de pruebas, respaldos de configuración, actas de conformidad. (Res. DNCP 230/25 sobre uso de catálogo, plantillas y atributos).
Garantías y soporte
a. Indiquen si el proveedor debe dejar firmware/OS en versión recomendada y entregar plan de reversión.
b. Señalen si se exige acompañamiento post–puesta en marcha (p. ej., N días de soporte onsite/remoto) y las SLA mínimas.
Criterios de medición y aceptación
a. Establezcan los hitos (recepción provisoria en sede Perú; instalación en DINAPI/MTESS; recepción definitiva) y los requisitos de aceptación por hito.
b. Indiquen si la recepción definitiva exigirá pruebas funcionales (por tipo de equipo) y qué resultados mínimos deberán evidenciarse.
Estas precisiones son necesarias para evitar que los oferentes asuman supuestos dispares de instalación que distorsionen los precios y afecten la comparabilidad de ofertas, contrariando los deberes de especificar necesidades “al nivel más detallado posible” y de planificar con base en las características técnicas y de mercado del objeto (Ley 7021/22, arts. 25 y 26).
Asimismo, recordamos que la precisión requerida puede y debe efectuarse mediante aclaración (sin alterar el PBC), respetando los plazos tope de consultas y respuestas en el SICP.
Petitorio:
Se solicita a la Convocante publicar Aclaración en el SICP que delimite el alcance de instalación y puesta en servicio conforme a los puntos 1 al 6 supra, o, alternativamente, disponer (y difundir) una visita técnica previa al tope de consultas para relevar condiciones de sitio y emitir luego la aclaración consolidada (art. 41 Res. DNCP 230/25).
A continuación, SE ACLARA se detalla el alcance técnico y operativo de los servicios de instalación requeridos, el cual se considera implícito en las Especificaciones Técnicas (EETT).
1. Para todos los equipos (Computadoras, Servidores, Storage, Switches)
a. Traslado seguro de los equipos desde el punto de recepción provisoria (MTESS Perú) hasta su ubicación final en los lugares designados (DINAPI y/o Sede Central MTESS).
b. Verificación física de que no existieron daños durante el transporte.
2. Para Servidores, Storage y Switches.
a. Conexión a las PDUs o UPS del rack
b. Realización del cableado de red necesario para interconectar los servidores con los switches y el storage.
c. Configuración inicial de gestión (ssh, usuarios, VLANs)
d. Configuración inicial del sistema de Almacenamiento.
e. Configuración de los grupos de discos y creación de los arreglos de discos.
f. Creación de los LUNs/Volúmenes y asignación a los servidores correspondientes.
g. Para servidores establecer conexión física y configuración lógica para el acceso al storage.
h. No incluye la instalación de sistemas operativos o aplicaciones.
3. Para Computadoras de Escritorio y Portátiles
a. Instalación Física: no se requiere.
b. Conexión básica: no se requiere.
c. No incluye: Instalación de software, migración de datos o configuración de perfiles de usuario.
El alcance detallado anteriormente es el mínimo necesario para cumplir con el espíritu de las EETT, que exigen que los equipos queden instalados y configurados para su operación óptima en el datacenter. Este nivel de servicio es estándar para proyectos de esta envergadura y complejidad técnica, considerando que se busca la provision DE BIENES.
Ademas, corresponde el estandar establecido por el MITIC para la adquisicion de equipos informaticos, que detalla los alcances de los bientes a ser adquiridos.
Por lo expuesto, se mantiene la especificación original sin modificación.
18
Ítem 5 – Switches
En el Ítem 5 – Switches, el PBC exige literalmente: “Soporte para QoS 802.1p, IP ToS, SP y WRR. Exigido.”.
Solicitamos a la Convocante aclarar el fundamento técnico por el cual se exigen expresamente los algoritmos “SP (Strict Priority) y WRR (Weighted Round Robin)”, en lugar de referir a estándares y prácticas internacionalmente aceptadas de Calidad de Servicio (QoS), dado que:
Riesgo de restricción por denominación
Diversos fabricantes de clase enterprise/datacenter implementan mecanismos equivalentes o superiores de priorización y gestión de colas, alineados con IEEE 802.1p, RFC 2474/2475 (DiffServ) y RFC 2597 (AF), aunque con nomenclaturas distintas (p. ej., variantes de colas estrictas y colas ponderadas). Exigir literalmente “SP y WRR” podría excluir soluciones equivalentes por solo diferir en la denominación comercial.
Marco normativo aplicable
El Decreto Reglamentario 2264/24 dispone que las especificaciones técnicas deben formularse con la mayor amplitud, ser claras, objetivas e imparciales, de modo a permitir la mayor concurrencia; cuando se recurra a signos distintivos no universales, debe usarse solo como referencia, procurando que la alusión se adecue a estándares internacionales comúnmente aceptados.
La Ley 7021/22 ordena que la convocante especifique al nivel más detallado posible el objeto y realice estudio de mercado para fijar condiciones acordes al contexto técnico y competitivo, lo cual incluye evitar requerimientos innecesariamente restrictivos que afecten la competencia y el valor por dinero.
La precisión solicitada corresponde a una aclaración (no adenda), conforme al glosario de la Res. DNCP 230/25.
Finalidad técnica del requisito
Entendemos que el objetivo es asegurar priorización de tráfico y gestión de colas ponderadas para distintos tipos/clases de servicio, no necesariamente limitar la solución a los nombres “SP” y “WRR”.
Petitorio
A fin de resguardar la igualdad de oportunidades, la concurrencia y la comparabilidad de ofertas, solicitamos:
a) Aclarar el motivo técnico de exigir literalmente “SP y WRR”. En caso de no existir una razón técnica objetiva y verificable para imponer esas denominaciones específicas,
b) Modificar o aclarar el requerimiento del Ítem 5 en los siguientes términos (u otros equivalentes basados en estándares):
“El switch deberá soportar mecanismos de Calidad de Servicio (QoS) basados en IEEE 802.1p, con priorización y gestión de colas ponderadas, o equivalentes funcionales, conforme a los estándares y RFCs internacionales vigentes.”
Esta redacción mantiene la exigencia técnica (QoS con priorización y colas ponderadas) pero elimina la restricción por denominación, alineándose a: (i) el mandato de especificaciones amplias, claras e imparciales y referidas a estándares internacionales (Decreto 2264/24, art. 58), y (ii) la obligación de definir necesidades y estudiar el mercado para promover la competencia y el valor por dinero (Ley 7021/22, arts. 25 y 26).
Asimismo, solicitamos que esta precisión se publique como Aclaración en el SICP.
En el Ítem 5 – Switches, el PBC exige literalmente: “Soporte para QoS 802.1p, IP ToS, SP y WRR. Exigido.”.
Solicitamos a la Convocante aclarar el fundamento técnico por el cual se exigen expresamente los algoritmos “SP (Strict Priority) y WRR (Weighted Round Robin)”, en lugar de referir a estándares y prácticas internacionalmente aceptadas de Calidad de Servicio (QoS), dado que:
Riesgo de restricción por denominación
Diversos fabricantes de clase enterprise/datacenter implementan mecanismos equivalentes o superiores de priorización y gestión de colas, alineados con IEEE 802.1p, RFC 2474/2475 (DiffServ) y RFC 2597 (AF), aunque con nomenclaturas distintas (p. ej., variantes de colas estrictas y colas ponderadas). Exigir literalmente “SP y WRR” podría excluir soluciones equivalentes por solo diferir en la denominación comercial.
Marco normativo aplicable
El Decreto Reglamentario 2264/24 dispone que las especificaciones técnicas deben formularse con la mayor amplitud, ser claras, objetivas e imparciales, de modo a permitir la mayor concurrencia; cuando se recurra a signos distintivos no universales, debe usarse solo como referencia, procurando que la alusión se adecue a estándares internacionales comúnmente aceptados.
La Ley 7021/22 ordena que la convocante especifique al nivel más detallado posible el objeto y realice estudio de mercado para fijar condiciones acordes al contexto técnico y competitivo, lo cual incluye evitar requerimientos innecesariamente restrictivos que afecten la competencia y el valor por dinero.
La precisión solicitada corresponde a una aclaración (no adenda), conforme al glosario de la Res. DNCP 230/25.
Finalidad técnica del requisito
Entendemos que el objetivo es asegurar priorización de tráfico y gestión de colas ponderadas para distintos tipos/clases de servicio, no necesariamente limitar la solución a los nombres “SP” y “WRR”.
Petitorio
A fin de resguardar la igualdad de oportunidades, la concurrencia y la comparabilidad de ofertas, solicitamos:
a) Aclarar el motivo técnico de exigir literalmente “SP y WRR”. En caso de no existir una razón técnica objetiva y verificable para imponer esas denominaciones específicas,
b) Modificar o aclarar el requerimiento del Ítem 5 en los siguientes términos (u otros equivalentes basados en estándares):
“El switch deberá soportar mecanismos de Calidad de Servicio (QoS) basados en IEEE 802.1p, con priorización y gestión de colas ponderadas, o equivalentes funcionales, conforme a los estándares y RFCs internacionales vigentes.”
Esta redacción mantiene la exigencia técnica (QoS con priorización y colas ponderadas) pero elimina la restricción por denominación, alineándose a: (i) el mandato de especificaciones amplias, claras e imparciales y referidas a estándares internacionales (Decreto 2264/24, art. 58), y (ii) la obligación de definir necesidades y estudiar el mercado para promover la competencia y el valor por dinero (Ley 7021/22, arts. 25 y 26).
Asimismo, solicitamos que esta precisión se publique como Aclaración en el SICP.
El requisito "Soporte para QoS 802.1p, IP ToS, SP y WRR" tiene como fundamento técnico para los diferentes tipo de tráficos críticos del MTESS y no es una imposición de una marca comercial. La mención explícita de "SP y WRR" se utiliza como referencia técnica universalmente comprendida para definir de manera clara e inequívoca el resultado funcional SP (Strict Priority - Prioridad Estricta) y WRR (Weighted Round Robin - Round Robin Ponderado).
La combinación de estos dos comportamientos (prioridad estricta + balanceo ponderado) es una arquitectura de scheduling robusta y ampliamente adoptada para cumplir con los objetivos de Calidad de Servicio en un entorno de datacenter.
Aclaración Oficial sobre el Cumplimiento del Requisito
En cumplimiento del principio de imparcialidad y referencia a estándares, se establece la siguiente aclaración oficial sobre el cumplimiento de este punto:
El requisito se considerará satisfecho si el oferente acredita, mediante documentación técnica oficial del fabricante (datasheets, manuales de configuración), que el switch propuesto implementa mecanismos de programación de colas (scheduling) que proveen una funcionalidad técnica equivalente a:
Un mecanismo de Prioridad Estricta (Strict Priority) para garantizar la mínima latencia para el tráfico más crítico.
Un mecanismo de Balanceo Ponderado (Weighted Round Robin) o su equivalente funcional (ej., Deficit WRR, Shaped Round Robin, etc.) para garantizar la distribución equitativa y controlada del ancho de banda entre las demás colas.
Por lo tanto, la evaluación se centrará en la funcionalidad provista y demostrada, y no en la nomenclatura específica utilizada por el fabricante.
No se modifica el texto del pliego, pero esta aclaración forma parte integral de la interpretación del requisito para todos los efectos de la presentación y evaluación de ofertas.
19
Para el ítem 4 Storage. Tiering automático
Solicitan: “Tiering automático: licenciado y activado para la capacidad solicitada.”
Solicitamos que el requerimiento de incluir tiering automático licenciado y activado sea opcional o, en su defecto, excluido. En sistemas completamente basados en tecnología NVMe, esta funcionalidad resulta innecesaria, ya que todos los discos ofrecen el mismo nivel de rendimiento y baja latencia. El tiering automático está diseñado para entornos híbridos con distintos tipos de medios (SSD y HDD), lo cual no aplica en arquitecturas full NVMe. Establecer esta característica como opcional o excluirlo, evita costos adicionales por licencias sin beneficio real, simplifica la administración y promueve una configuración más eficiente y moderna, la consulta es cursada con el fin de poder flexibilizar el presente requerimiento y poder permitir la participación de marcas y modelos que cumplen con todas las demás especificaciones requeridas, de tal forma a no limitar con dicha exigencia establecida.
Solicitan: “Tiering automático: licenciado y activado para la capacidad solicitada.”
Solicitamos que el requerimiento de incluir tiering automático licenciado y activado sea opcional o, en su defecto, excluido. En sistemas completamente basados en tecnología NVMe, esta funcionalidad resulta innecesaria, ya que todos los discos ofrecen el mismo nivel de rendimiento y baja latencia. El tiering automático está diseñado para entornos híbridos con distintos tipos de medios (SSD y HDD), lo cual no aplica en arquitecturas full NVMe. Establecer esta característica como opcional o excluirlo, evita costos adicionales por licencias sin beneficio real, simplifica la administración y promueve una configuración más eficiente y moderna, la consulta es cursada con el fin de poder flexibilizar el presente requerimiento y poder permitir la participación de marcas y modelos que cumplen con todas las demás especificaciones requeridas, de tal forma a no limitar con dicha exigencia establecida.
Se mantiene la especificación original de "Tiering automático: licenciado y activado para la capacidad solicitada" sin modificación.
Este requisito es técnicamente sólido y estratégico. Garantiza que la solución adjudicada no sea solo un conjunto de hardware de alto rendimiento, sino un sistema inteligente y preparado para el futuro, con capacidades de software empresarial que permiten una operación optimizada, automatizada y escalable.
La ausencia de esta funcionalidad es un indicador de soluciones de gama básica que no se alinean con los requisitos de un datacenter ministerial crítico. Por lo tanto, la especificación no restringe la competencia injustificadamente, sino que establece un nivel de calidad software mínimo y uniforme para todos los oferentes, asegurando que el MTESS adquiera una solución completa y con visión a largo plazo.
20
Ítem 4 – Storage
En el Ítem 4 – Storage el PBC exige: “Tiering automático: licenciado y activado para la capacidad solicitada.”
Se observa que el requisito no distingue el tipo de arquitectura del sistema de almacenamiento. El tiering automático es una función típicamente utilizada en sistemas híbridos (HDD/SSD) para desplazar datos fríos a medios de menor costo/rendimiento. En cambio, en arquitecturas All-Flash NVMe, como las solicitadas para este ítem, no existe un nivel inferior dentro del arreglo principal (todo reside en medios de alta performance y baja latencia), por lo que el “tiering local” resulta técnicamente innecesario. En estos entornos, las funciones de movimiento de datos que existen suelen orientarse a tiers externos (nube/otros nodos del clúster) y no impactan la operación local ni el rendimiento del arreglo.
Mantener el requisito como obligatorio en una arquitectura All-Flash NVMe pura podría excluir soluciones de última generación que, por diseño, prescinden del “tiering local” para privilegiar simplicidad y latencias ultrabajas, sin afectar la eficiencia ni la gestión del almacenamiento.
Las especificaciones técnicas deben redactarse con la mayor amplitud, de forma clara, objetiva e imparcial, a fin de permitir la mayor concurrencia, y cuando se acuda a rasgos no universales se los debe usar solo como referencia procurando alineación a estándares internacionales.
La convocante debe especificar al nivel más detallado posible lo necesario y realizar estudio de mercado, atendiendo el contexto técnico y la competencia disponible, para fijar condiciones proporcionales que aseguren valor por dinero.
Rigen los principios de igualdad y libre competencia, que obligan a evitar exigencias que, sin justificación técnica objetiva, restrinjan la participación.
La precisión solicitada corresponde a una aclaración (no adenda), la cual se integra al documento aclarado y debe difundirse en el SICP dentro de los plazos.
Petitorio: A fin de asegurar comparabilidad, concurrencia y razonabilidad técnica, solicitamos:
Aclarar el alcance del requisito “tiering automático”, indicando en qué escenarios aplica (p. ej., solo cuando el sistema posea múltiples tipos de medios dentro del mismo arreglo y exista un tier de menor performance local).
Modificar/Flexibilizar la redacción del punto, proponiendo el siguiente texto (o equivalente basado en estándares):
Redacción sugerida: “Si el sistema de almacenamiento cuenta con múltiples tipos de medios (HDD, SSD u otros) dentro del arreglo, deberá disponer de funciones de tiering automático debidamente licenciadas y activadas para la capacidad ofertada. En sistemas All-Flash NVMe, donde todos los datos residen en medios de alto rendimiento, el requerimiento de tiering automático local se considerará no aplicable, pudiendo sustituirse por mecanismos equivalentes de optimización (p. ej., balanceo dentro del clúster, data-placement, compresión/dedupe, o políticas de movilidad hacia nube/u otros nodos) sin detrimento del desempeño ni de la gestión.”
Esta adecuación mantiene el objetivo funcional (gestión eficiente del almacenamiento) y elimina una exigencia innecesaria para la arquitectura All-Flash NVMe, alineando el PBC con los deberes de: (i) amplitud y neutralidad en la especificación para maximizar la concurrencia, (ii) detalle razonable conforme al contexto técnico y a la competencia de mercado, y (iii) igualdad y libre competencia entre oferentes.
Asimismo, solicitamos que la precisión se publique como Aclaración en el SICP, dentro de los plazos establecidos.
En el Ítem 4 – Storage el PBC exige: “Tiering automático: licenciado y activado para la capacidad solicitada.”
Se observa que el requisito no distingue el tipo de arquitectura del sistema de almacenamiento. El tiering automático es una función típicamente utilizada en sistemas híbridos (HDD/SSD) para desplazar datos fríos a medios de menor costo/rendimiento. En cambio, en arquitecturas All-Flash NVMe, como las solicitadas para este ítem, no existe un nivel inferior dentro del arreglo principal (todo reside en medios de alta performance y baja latencia), por lo que el “tiering local” resulta técnicamente innecesario. En estos entornos, las funciones de movimiento de datos que existen suelen orientarse a tiers externos (nube/otros nodos del clúster) y no impactan la operación local ni el rendimiento del arreglo.
Mantener el requisito como obligatorio en una arquitectura All-Flash NVMe pura podría excluir soluciones de última generación que, por diseño, prescinden del “tiering local” para privilegiar simplicidad y latencias ultrabajas, sin afectar la eficiencia ni la gestión del almacenamiento.
Las especificaciones técnicas deben redactarse con la mayor amplitud, de forma clara, objetiva e imparcial, a fin de permitir la mayor concurrencia, y cuando se acuda a rasgos no universales se los debe usar solo como referencia procurando alineación a estándares internacionales.
La convocante debe especificar al nivel más detallado posible lo necesario y realizar estudio de mercado, atendiendo el contexto técnico y la competencia disponible, para fijar condiciones proporcionales que aseguren valor por dinero.
Rigen los principios de igualdad y libre competencia, que obligan a evitar exigencias que, sin justificación técnica objetiva, restrinjan la participación.
La precisión solicitada corresponde a una aclaración (no adenda), la cual se integra al documento aclarado y debe difundirse en el SICP dentro de los plazos.
Petitorio: A fin de asegurar comparabilidad, concurrencia y razonabilidad técnica, solicitamos:
Aclarar el alcance del requisito “tiering automático”, indicando en qué escenarios aplica (p. ej., solo cuando el sistema posea múltiples tipos de medios dentro del mismo arreglo y exista un tier de menor performance local).
Modificar/Flexibilizar la redacción del punto, proponiendo el siguiente texto (o equivalente basado en estándares):
Redacción sugerida: “Si el sistema de almacenamiento cuenta con múltiples tipos de medios (HDD, SSD u otros) dentro del arreglo, deberá disponer de funciones de tiering automático debidamente licenciadas y activadas para la capacidad ofertada. En sistemas All-Flash NVMe, donde todos los datos residen en medios de alto rendimiento, el requerimiento de tiering automático local se considerará no aplicable, pudiendo sustituirse por mecanismos equivalentes de optimización (p. ej., balanceo dentro del clúster, data-placement, compresión/dedupe, o políticas de movilidad hacia nube/u otros nodos) sin detrimento del desempeño ni de la gestión.”
Esta adecuación mantiene el objetivo funcional (gestión eficiente del almacenamiento) y elimina una exigencia innecesaria para la arquitectura All-Flash NVMe, alineando el PBC con los deberes de: (i) amplitud y neutralidad en la especificación para maximizar la concurrencia, (ii) detalle razonable conforme al contexto técnico y a la competencia de mercado, y (iii) igualdad y libre competencia entre oferentes.
Asimismo, solicitamos que la precisión se publique como Aclaración en el SICP, dentro de los plazos establecidos.
El requisito de "Tiering automático: licenciado y activado para la capacidad solicitada" se entiende técnicamente como la exigencia de un sistema de gestión de datos inteligente y automatizado, capacidad fundamental en un sistema de almacenamiento empresarial moderno, incluso en arquitecturas All-Flash NVMe.
Aclaración Oficial sobre el Cumplimiento del Requisito.
En atención a los principios de neutralidad tecnológica y de referirse a funcionalidades y no a nomenclaturas específicas, se establece lo siguiente:
El requisito de "Tiering Automático" se considerará cumplido si el oferente acredita, mediante documentación técnica oficial del fabricante (datasheets, manuales), que el sistema de almacenamiento propuesto incluye de serie (licenciado y activado) para la capacidad ofertada, un módulo o funcionalidad de software que realice una o varias de las siguientes acciones de forma automatizada y basada en políticas:
Optimización Interna de la Ubicación de Datos: Mecanismos de "Data Placement", "Balanceo de Carga" o "Optimización Intra-Array" que mejoren activamente el rendimiento, la durabilidad del medio o la eficiencia dentro del pool principal de almacenamiento All-Flash NVMe.
Movilidad de Datos hacia Nubes Públicas o Privadas: Funcionalidades de "Cloud Tiering" o "Extensiones hacia Nube" que permitan la movilidad de datos entre el sistema local y servicios de nube pública o privada.
Movilidad de Datos entre Nodos de un Clúster: En arquitecturas de clúster, mecanismos que balanceen o muevan datos automáticamente entre los distintos nodos para optimizar el rendimiento o la resiliencia.
La evaluación se centrará en la existencia de capacidades de gestión automatizada de datos equivalentes en su propósito y sofisticación, y no en la denominación comercial específica "Tiering Automático".