De conformidad con lo establecido en el Pliego de Bases y Condiciones, el presente llamado prevé la adjudicación por el total del lote.
Atendiendo a la naturaleza de los bienes solicitados, que son independientes entre sí y pueden ser provistos por distintos oferentes, solicitamos a la Entidad Convocante que modifique el criterio de adjudicación de 'por el total' a 'por ítems', de manera a fomentar la mayor participación y competencia, lo que además resultaría beneficioso para la administración al obtener mejores precios unitarios.
De conformidad con lo establecido en el Pliego de Bases y Condiciones, el presente llamado prevé la adjudicación por el total del lote.
Atendiendo a la naturaleza de los bienes solicitados, que son independientes entre sí y pueden ser provistos por distintos oferentes, solicitamos a la Entidad Convocante que modifique el criterio de adjudicación de 'por el total' a 'por ítems', de manera a fomentar la mayor participación y competencia, lo que además resultaría beneficioso para la administración al obtener mejores precios unitarios.
Se ha considerado la consulta, favor remitirse a la Adenda
2
Plazo de Entrega de Bienes
Solicitamos respetuosamente a la convocante aclarar si el ITEM 2 Computadora Portatil Avanzada se requiere la provisión de 24 o 30 unidades, teniendo en cuenta que en el PBC en el apartado "Plan de Entrega de Bienes" menciona 30 unidades pero en "Items Solicitados" menciona 24 unidades. Aprovechamos la oportunidad para solicitar la unificación del plazo de entrega de los equipos solicitados a 210 dias habiles contados del dia siguiente de la recepción de la orden de compra, mantener el requerimiento de 30 dias habiles unicamente evita una mayor participación de potenciales oferentes.
Solicitamos respetuosamente a la convocante aclarar si el ITEM 2 Computadora Portatil Avanzada se requiere la provisión de 24 o 30 unidades, teniendo en cuenta que en el PBC en el apartado "Plan de Entrega de Bienes" menciona 30 unidades pero en "Items Solicitados" menciona 24 unidades. Aprovechamos la oportunidad para solicitar la unificación del plazo de entrega de los equipos solicitados a 210 dias habiles contados del dia siguiente de la recepción de la orden de compra, mantener el requerimiento de 30 dias habiles unicamente evita una mayor participación de potenciales oferentes.
Se ha procedido a adendar la inconsistencia existente. Favor remitirse a la adenda. Se indica que el plazo establecido fue fijado en base a la necesidad institucional dentro del presente ejercicio y la disponibilidad presupuestaria. Favor ajustarse a lo establecido en el PBC
3
Plazos de presentación
Teniendo en cuenta la complejidad de items como el 3 y el 4, solicitamos favor prorrogar al menos 2 a 3 días el plazo de presentación de ofertas y también el plazo límite para realizar consultas, de modo a dar mayor plazo para análisis a los oferentes. Con esto la convocante podrá tener la certeza de que los oferentes podran ofertar las mejores opciones y más económicas posibles que cumplan con lo requerido, atendiendo a que no todas las empresas o fabricantes pueden obtener en tan poco tiempo de las mejores opciones disponibles.
Teniendo en cuenta la complejidad de items como el 3 y el 4, solicitamos favor prorrogar al menos 2 a 3 días el plazo de presentación de ofertas y también el plazo límite para realizar consultas, de modo a dar mayor plazo para análisis a los oferentes. Con esto la convocante podrá tener la certeza de que los oferentes podran ofertar las mejores opciones y más económicas posibles que cumplan con lo requerido, atendiendo a que no todas las empresas o fabricantes pueden obtener en tan poco tiempo de las mejores opciones disponibles.
Se ha procedido a otorgar dos prorrogas y a habilitar nuevamente las consultas. Favor tomar en cuenta el periodo de cierre de procesos y que no se podran otorgar mas extensiones.
El PBC indica:
“Usando la tecnología de disco SSD NVMe, proveer al menos 60TB en RAID 10 utilizables entre la caja principal y sus expansiones de discos, ya teniendo en cuenta el formateo y arreglos de discos, y sin tener en cuenta los ahorros por compresión, deduplicación, compactación u otras tecnologías de ahorro similares.
El sistema de almacenamiento debe tener la capacidad de proveer arreglos RAID 6 y RAID 10.
Las expansiones deben soportar como mínimo 93 discos NVMe en total.”
El requerimiento establece que el sistema de almacenamiento deberá soportar exclusivamente RAID 6 y RAID 10, lo cual restringe la participación de fabricantes que emplean tecnologías de protección de datos optimizadas para entornos de almacenamiento empresarial.
En la actualidad, varios fabricantes de primera línea utilizan tecnologías RAID avanzadas y propietarias, diseñadas específicamente para entornos All-Flash NVMe, entre ellas RAID-TEC, RAID-DP, RAID-DO, o RAID-4, las cuales ofrecen mayor eficiencia, resiliencia y tolerancia a fallos que los esquemas tradicionales RAID 6 y RAID 10. Asimismo, sugerimos revisar el requerimiento que exige que las expansiones soporten un número específico de 93 discos NVMe, dado que cada fabricante implementa arquitecturas modulares distintas.
Por lo tanto, solicitamos modificar la redacción del punto, a fin de que el pliego no limite las soluciones a una tecnología RAID específica, sino que admita tecnologías equivalentes o superiores en prestaciones, de acuerdo con el principio de igualdad de oportunidades entre oferentes prevista en la Ley N.º 7021/2022.
En consecuencia, solicitamos reemplazar dicho requerimiento fijo por una redacción más inclusiva, como por ej:
“El sistema de almacenamiento deberá contar con mecanismos de protección de datos equivalentes o superiores a RAID 6 y RAID 10, pudiendo utilizar tecnologías de paridad o distribución optimizadas especialmente para almacenamiento All-Flash como RAID-4, RAID-DP, RAID-DO, RAID-TEC o superiores en funcionalidad.
El sistema deberá permitir la expansión modular mediante la adición de gabinetes o shelves NVMe, de acuerdo con la arquitectura del fabricante.”
Esta modificación no altera el propósito técnico del requerimiento, pero evita direccionamiento a un fabricante o modelo específico, garantizando la participación de una mayor cantidad de oferentes calificados y respetando los principios de concurrencia, igualdad y neutralidad tecnológica establecidos en la Ley de Contrataciones Públicas.
El PBC indica:
“Usando la tecnología de disco SSD NVMe, proveer al menos 60TB en RAID 10 utilizables entre la caja principal y sus expansiones de discos, ya teniendo en cuenta el formateo y arreglos de discos, y sin tener en cuenta los ahorros por compresión, deduplicación, compactación u otras tecnologías de ahorro similares.
El sistema de almacenamiento debe tener la capacidad de proveer arreglos RAID 6 y RAID 10.
Las expansiones deben soportar como mínimo 93 discos NVMe en total.”
El requerimiento establece que el sistema de almacenamiento deberá soportar exclusivamente RAID 6 y RAID 10, lo cual restringe la participación de fabricantes que emplean tecnologías de protección de datos optimizadas para entornos de almacenamiento empresarial.
En la actualidad, varios fabricantes de primera línea utilizan tecnologías RAID avanzadas y propietarias, diseñadas específicamente para entornos All-Flash NVMe, entre ellas RAID-TEC, RAID-DP, RAID-DO, o RAID-4, las cuales ofrecen mayor eficiencia, resiliencia y tolerancia a fallos que los esquemas tradicionales RAID 6 y RAID 10. Asimismo, sugerimos revisar el requerimiento que exige que las expansiones soporten un número específico de 93 discos NVMe, dado que cada fabricante implementa arquitecturas modulares distintas.
Por lo tanto, solicitamos modificar la redacción del punto, a fin de que el pliego no limite las soluciones a una tecnología RAID específica, sino que admita tecnologías equivalentes o superiores en prestaciones, de acuerdo con el principio de igualdad de oportunidades entre oferentes prevista en la Ley N.º 7021/2022.
En consecuencia, solicitamos reemplazar dicho requerimiento fijo por una redacción más inclusiva, como por ej:
“El sistema de almacenamiento deberá contar con mecanismos de protección de datos equivalentes o superiores a RAID 6 y RAID 10, pudiendo utilizar tecnologías de paridad o distribución optimizadas especialmente para almacenamiento All-Flash como RAID-4, RAID-DP, RAID-DO, RAID-TEC o superiores en funcionalidad.
El sistema deberá permitir la expansión modular mediante la adición de gabinetes o shelves NVMe, de acuerdo con la arquitectura del fabricante.”
Esta modificación no altera el propósito técnico del requerimiento, pero evita direccionamiento a un fabricante o modelo específico, garantizando la participación de una mayor cantidad de oferentes calificados y respetando los principios de concurrencia, igualdad y neutralidad tecnológica establecidos en la Ley de Contrataciones Públicas.
Estos esquemas (RAID 10 y RAID 6) son estándares de la industria, ampliamente documentados, soportados y con comportamientos de rendimiento y resiliencia predecibles. Esto garantiza que el personal técnico del MTESS pueda operar y mantener el sistema con procedimientos conocidos, minimizando riesgos operativos.
El uso de estándares RAID conocidos permite una evaluación objetiva, comparable y transparente entre todas las ofertas, alineándose con el principio de igualdad. Los esquemas propietarios, al ser cerrados, dificultan esta comparación homogénea.
Este número (93 discos NVMe) garantiza la escalabilidad futura y es un parámetro de diseño que asegura que la solución entregada tendrá la capacidad de expansión suficiente para los próximos años, sin quedarse obsoleta a corto plazo.
La redacción actual ya es técnica y funcionalmente neutral, ya que cualquier fabricante puede cumplir con los esquemas RAID estándar solicitados. Los oferentes que utilicen tecnologías propietarias tienen la oportunidad, dentro de su propuesta, de demostrar de manera fehaciente (con hojas de datos, benchmarks, documentación técnica) que su solución equivalente o superior cumple con el resultado funcional requerido por las EETT, siendo este un elemento valorable en la evaluación técnica.
Esta postura no infringe los principios de concurrencia, igualdad o neutralidad tecnológica, sino que establece un criterio de evaluación claro, objetivo y demostrable para todos los participantes por igual, garantizando que la solución adjudicada cumpla con las necesidades técnicas y operativas críticas del MTESS.
Por lo expuesto, se mantienen las especificaciones originales sin modificación.
5
Consulta N.º 2 – Controladoras y Bahías de Discos
Para el item 4 – Storage se solicita:
“Dos controladoras instaladas trabajando de manera redundante. En caso de falla de una de las controladoras el storage debe seguir funcionado. Hot-Swap. Al menos 256GB de caché instalado por controladora (512GB de caché en total). La caja principal debe soportar como mínimo 25 bahías de discos. En la caja/chasis principal y en las expansiones se debe utilizar tecnología de disco NVMe.”
El requerimiento actual impone que cada controladora cuente con al menos 256GB de caché y que la caja principal posea un mínimo de 25 bahías de discos NVMe.
Deseamos señalar que este requerimiento limita innecesariamente la participación de fabricantes líderes en almacenamiento de nivel empresarial, cuyas arquitecturas modernas utilizan mecanismos de optimización de memoria distintos al caché tradicional, combinando memoria DRAM + NVRAM y procesadores especializados que garantizan igual o superior rendimiento con menores cantidades nominales de caché.
También observamos que la exigencia de “25 bahías mínimas en la caja principal” no se ajusta a los estándares de diseño modulares actuales, donde los sistemas base ofrecen 24 bahías NVMe por unidad y expanden la capacidad mediante shelves adicionales conectados en cascada. Dicha arquitectura modular ofrece las mismas prestaciones de rendimiento y disponibilidad, pero con mejor escalabilidad y mantenimiento, especialmente en entornos NVMe. Con estas observaciones solicitamos que se modifique la redacción del punto, de modo que no limite la participación de fabricantes que cumplan funcionalmente los objetivos de redundancia, rendimiento y escalabilidad.
Por lo tanto, y a fin de evitar un posible direccionamiento y beneficio a una marca específica se propone la sgte redacción:
“El sistema deberá contar con al menos dos controladoras instaladas en modo activo-activo o redundante, con capacidad de operación continua ante falla de una de ellas (Hot-Swap). Cada controladora deberá disponer de memoria caché o memoria optimizada equivalente (DRAM/NVRAM u otra tecnología de rendimiento equivalente o superior), que garantice la continuidad y la integridad de los datos, con un mínimo de 128GB por controladora. El sistema deberá soportar al menos 24 bahías NVMe en el chasis principal o su equivalente modular de acuerdo con la arquitectura del fabricante, permitiendo expansión mediante shelves adicionales.”
Esta solicitud se sustenta en el principio de igualdad de oportunidades entre oferentes, establecido por la ley de contrataciones públicas, que prohíbe imponer requisitos que restrinjan la concurrencia o direccionen el llamado hacia marcas o modelos específicos. La modificación propuesta mantiene las prestaciones técnicas solicitadas deredundancia, capacidad, NVMe y disponibilidad, pero permite la participación de soluciones equivalentes o superiores, garantizando la libre competencia y una mayor eficiencia económica para la convocante.
“Dos controladoras instaladas trabajando de manera redundante. En caso de falla de una de las controladoras el storage debe seguir funcionado. Hot-Swap. Al menos 256GB de caché instalado por controladora (512GB de caché en total). La caja principal debe soportar como mínimo 25 bahías de discos. En la caja/chasis principal y en las expansiones se debe utilizar tecnología de disco NVMe.”
El requerimiento actual impone que cada controladora cuente con al menos 256GB de caché y que la caja principal posea un mínimo de 25 bahías de discos NVMe.
Deseamos señalar que este requerimiento limita innecesariamente la participación de fabricantes líderes en almacenamiento de nivel empresarial, cuyas arquitecturas modernas utilizan mecanismos de optimización de memoria distintos al caché tradicional, combinando memoria DRAM + NVRAM y procesadores especializados que garantizan igual o superior rendimiento con menores cantidades nominales de caché.
También observamos que la exigencia de “25 bahías mínimas en la caja principal” no se ajusta a los estándares de diseño modulares actuales, donde los sistemas base ofrecen 24 bahías NVMe por unidad y expanden la capacidad mediante shelves adicionales conectados en cascada. Dicha arquitectura modular ofrece las mismas prestaciones de rendimiento y disponibilidad, pero con mejor escalabilidad y mantenimiento, especialmente en entornos NVMe. Con estas observaciones solicitamos que se modifique la redacción del punto, de modo que no limite la participación de fabricantes que cumplan funcionalmente los objetivos de redundancia, rendimiento y escalabilidad.
Por lo tanto, y a fin de evitar un posible direccionamiento y beneficio a una marca específica se propone la sgte redacción:
“El sistema deberá contar con al menos dos controladoras instaladas en modo activo-activo o redundante, con capacidad de operación continua ante falla de una de ellas (Hot-Swap). Cada controladora deberá disponer de memoria caché o memoria optimizada equivalente (DRAM/NVRAM u otra tecnología de rendimiento equivalente o superior), que garantice la continuidad y la integridad de los datos, con un mínimo de 128GB por controladora. El sistema deberá soportar al menos 24 bahías NVMe en el chasis principal o su equivalente modular de acuerdo con la arquitectura del fabricante, permitiendo expansión mediante shelves adicionales.”
Esta solicitud se sustenta en el principio de igualdad de oportunidades entre oferentes, establecido por la ley de contrataciones públicas, que prohíbe imponer requisitos que restrinjan la concurrencia o direccionen el llamado hacia marcas o modelos específicos. La modificación propuesta mantiene las prestaciones técnicas solicitadas deredundancia, capacidad, NVMe y disponibilidad, pero permite la participación de soluciones equivalentes o superiores, garantizando la libre competencia y una mayor eficiencia económica para la convocante.
Los requisitos de 512 GB de caché total (256 GB de caché por controladora) y 25 bahías mínimas en el chasis principal son parámetros técnicos necesarios para operativas del MTESS (bases de datos, servidores de aplicaciones web, sistemas de reportes, sistema de analíticas, entre otros), diseñados para garantizar el rendimiento, la capacidad de expansión y la resiliencia requeridas. Múltiples fabricantes de nivel empresarial ofrecen soluciones que cumplen con estos parámetros. Los principios de igualdad y libre competencia se preservan, ya que todos los oferentes tienen la misma oportunidad de presentar soluciones que cumplan con estas especificaciones técnicas claras y objetivas. Por lo expuesto, se mantienen las especificaciones originales sin modificación.
6
Consulta N.º 3 – Funcionalidad de Tiering Automático
Para el item 4 – Storage se solicita:
“Tiering automático: licenciado y activado para la capacidad solicitada.”
El requerimiento técnico exige que el equipo ofertado disponga de tiering automático licenciado y activado, sin distinguir el tipo de tecnología de almacenamiento a la cual aplica dicha función.
El tiering es una característica utilizada principalmente en sistemas híbridos (HDD/SSD), donde los datos menos utilizados se trasladan automáticamente hacia discos de menor costo o rendimiento. Sin embargo, en sistemas All-Flash NVMe como el solicitado para este ítem, no existe un segundo nivel de almacenamiento de menor performance, ya que toda la información reside en medios de máxima velocidad y baja latencia.
Los entornos para los que se solicitan las funciones de tiering, aplican únicamente para movimiento de datos hacia la nube o hacia otros nodos dentro de un clúster, lo cual no tiene impacto en la operación local del sistema ni en el rendimiento general. Dicho esto, manifestamos que mantener este requisito como obligatorio carece de sentido técnico en arquitecturas NVMe puras como la aquí solicitada y podría excluir equipos de última generación que prescinden de dicha función por diseño, priorizando la simplicidad y la latencia ultrabaja.
Ante lo expresado, exigimos modificar o flexibilizar este punto, permitiendo que los oferentes cumplan el objetivo de gestión eficiente del almacenamiento, sin exigir la función de tiering automático local en sistemas All-Flash NVMe.
Se propone una redacción como la siguiente:
“En caso de que el sistema de almacenamiento cuente con múltiples tipos de medios (HDD, SSD u otros), deberá disponer de funciones de tiering automático licenciadas y activadas. En sistemas All-Flash NVMe, donde toda la información reside en medios de alto rendimiento, esta función será considerada no aplicable, pudiendo reemplazarse por mecanismos equivalentes de optimización o balanceo de carga dentro del clúster o hacia la nube.”
La presente consulta se formula conforme al Artículo 4° de la Ley N.º 7021/2022, que establece los principios de igualdad, libre concurrencia y neutralidad tecnológica.
La exigencia actual restringe la participación de fabricantes que emplean arquitecturas All-Flash NVMe modernas, donde la función de tiering automático resulta técnicamente innecesaria, configurando así un posible direccionamiento hacia soluciones híbridas o específicas de un fabricante.
15-10-2025
27-10-2025
Consulta N.º 3 – Funcionalidad de Tiering Automático
Para el item 4 – Storage se solicita:
“Tiering automático: licenciado y activado para la capacidad solicitada.”
El requerimiento técnico exige que el equipo ofertado disponga de tiering automático licenciado y activado, sin distinguir el tipo de tecnología de almacenamiento a la cual aplica dicha función.
El tiering es una característica utilizada principalmente en sistemas híbridos (HDD/SSD), donde los datos menos utilizados se trasladan automáticamente hacia discos de menor costo o rendimiento. Sin embargo, en sistemas All-Flash NVMe como el solicitado para este ítem, no existe un segundo nivel de almacenamiento de menor performance, ya que toda la información reside en medios de máxima velocidad y baja latencia.
Los entornos para los que se solicitan las funciones de tiering, aplican únicamente para movimiento de datos hacia la nube o hacia otros nodos dentro de un clúster, lo cual no tiene impacto en la operación local del sistema ni en el rendimiento general. Dicho esto, manifestamos que mantener este requisito como obligatorio carece de sentido técnico en arquitecturas NVMe puras como la aquí solicitada y podría excluir equipos de última generación que prescinden de dicha función por diseño, priorizando la simplicidad y la latencia ultrabaja.
Ante lo expresado, exigimos modificar o flexibilizar este punto, permitiendo que los oferentes cumplan el objetivo de gestión eficiente del almacenamiento, sin exigir la función de tiering automático local en sistemas All-Flash NVMe.
Se propone una redacción como la siguiente:
“En caso de que el sistema de almacenamiento cuente con múltiples tipos de medios (HDD, SSD u otros), deberá disponer de funciones de tiering automático licenciadas y activadas. En sistemas All-Flash NVMe, donde toda la información reside en medios de alto rendimiento, esta función será considerada no aplicable, pudiendo reemplazarse por mecanismos equivalentes de optimización o balanceo de carga dentro del clúster o hacia la nube.”
La presente consulta se formula conforme al Artículo 4° de la Ley N.º 7021/2022, que establece los principios de igualdad, libre concurrencia y neutralidad tecnológica.
La exigencia actual restringe la participación de fabricantes que emplean arquitecturas All-Flash NVMe modernas, donde la función de tiering automático resulta técnicamente innecesaria, configurando así un posible direccionamiento hacia soluciones híbridas o específicas de un fabricante.
Si bien es correcto que el tiering clásico (entre HDD y SSD) no aplica en un sistema All-Flash, el requisito de "Tiering automático" en este contexto se refiere a funciones avanzadas de gestión inteligente de datos que son críticas incluso en entornos NVMe puros. Por el contrario, confirmar que un sistema All-Flash NVMe carece por completo de esta capacidad podría indicar que se trata de una solución de gama básica o no empresarial, que no cumple con los requisitos de gestión automatizada y escalabilidad futura del MTESS. Su exigencia asegura que el MTESS adquiera una solución robusta, con todas las funcionalidades de software necesarias para una operación eficiente y una planificación futura.
Por lo expuesto, se mantiene la especificación original sin modificación.
7
CONSULTA N.º 4 – Transceptores homologados
Para el ítem 5 – Switches se solicita:
“Los transceptores y Stack cables deben estar homologados y certificados de acuerdo a la documentación técnica de los switches ofertados.
No se aceptarán componentes compatibles pero que no estén certificados u homologados por el fabricante de los switches ofertados.”
Solicitamos a la convocante revisar y aclarar el alcance del requerimiento citado, dado que su redacción actual restringe la competencia únicamente a los transceptores y cables de marca idéntica al switch ofertado, sin contemplar la posibilidad de utilizar módulos transceptores homologados o validados oficialmente por el fabricante del switch, tal como lo permiten la mayoría de los fabricantes internacionales de nivel corporativo
Esta limitación resulta contraria al principio de libre competencia que obliga a las entidades contratantes a redactar los pliegos de modo que no favorezcan a un fabricante o modelo determinado.
Cabe aclarar que los fabricantes de transceptores de gama alta publican matrices de compatibilidad para los módulos transceptores que se encuentran homologados o validados oficialmente para operar con switches de marcas referentes, sin la necesidad de ser de la misma marca comercial. Estos transceptores homologados cumplen con normas internacionales y garantizan interoperabilidad y funcionamiento pleno, sin afectar la garantía del fabricante. Solicitamos que el punto sea modificado o aclarado con la siguiente redacción alternativa:
“Los transceptores ópticos y cables stack deberán ser homologados o certificados por el fabricante del switch ofertado y/o por el fabricante del transceptor ofertado, conforme a listas oficiales de compatibilidad, y deberán cumplir las normas internacionales vigentes aplicables al item solicitado. No se aceptarán componentes genéricos que no estén reconocidos como compatibles por el fabricante del equipo.”
Esta modificación mantiene el requisito de calidad y compatibilidad técnica, pero elimina el direccionamiento de marca, permitiendo el uso de módulos homologados que el propio fabricante reconoce oficialmente. De este modo, se garantiza libre concurrencia, igualdad de condiciones, y cumplimiento con la de Contrataciones Públicas, sin comprometer la integridad técnica de la solución.
Para el ítem 5 – Switches se solicita:
“Los transceptores y Stack cables deben estar homologados y certificados de acuerdo a la documentación técnica de los switches ofertados.
No se aceptarán componentes compatibles pero que no estén certificados u homologados por el fabricante de los switches ofertados.”
Solicitamos a la convocante revisar y aclarar el alcance del requerimiento citado, dado que su redacción actual restringe la competencia únicamente a los transceptores y cables de marca idéntica al switch ofertado, sin contemplar la posibilidad de utilizar módulos transceptores homologados o validados oficialmente por el fabricante del switch, tal como lo permiten la mayoría de los fabricantes internacionales de nivel corporativo
Esta limitación resulta contraria al principio de libre competencia que obliga a las entidades contratantes a redactar los pliegos de modo que no favorezcan a un fabricante o modelo determinado.
Cabe aclarar que los fabricantes de transceptores de gama alta publican matrices de compatibilidad para los módulos transceptores que se encuentran homologados o validados oficialmente para operar con switches de marcas referentes, sin la necesidad de ser de la misma marca comercial. Estos transceptores homologados cumplen con normas internacionales y garantizan interoperabilidad y funcionamiento pleno, sin afectar la garantía del fabricante. Solicitamos que el punto sea modificado o aclarado con la siguiente redacción alternativa:
“Los transceptores ópticos y cables stack deberán ser homologados o certificados por el fabricante del switch ofertado y/o por el fabricante del transceptor ofertado, conforme a listas oficiales de compatibilidad, y deberán cumplir las normas internacionales vigentes aplicables al item solicitado. No se aceptarán componentes genéricos que no estén reconocidos como compatibles por el fabricante del equipo.”
Esta modificación mantiene el requisito de calidad y compatibilidad técnica, pero elimina el direccionamiento de marca, permitiendo el uso de módulos homologados que el propio fabricante reconoce oficialmente. De este modo, se garantiza libre concurrencia, igualdad de condiciones, y cumplimiento con la de Contrataciones Públicas, sin comprometer la integridad técnica de la solución.
Si un transceptor de la "Marca A", homologado por sí mismo para un switch de la "Marca B", falla y causa un problema en el switch, se genera un conflicto de responsabilidades entre la "Marca A" (del transceptor) y la "Marca B" (del switch)
Una lista publicada por un fabricante de transceptores no tiene el mismo peso contractual que una certificación del fabricante del switch. El fabricante del switch puede negar soporte basándose en que el componente no es el suyo, a pesar de lo que indique la lista del tercero.
La verificación de la oferta se vuelve más compleja, requiriendo cruzar listas de compatibilidad de dos fabricantes diferentes, lo que abre espacio a interpretaciones y potenciales incumplimientos.
Este requisito garantiza que el MTESS reciba una solución integral y confiable, eliminando riesgos operativos futuros.
Por lo expuesto, se mantiene la especificación original sin modificación.
8
CONSULTA N.º 5 – Stacking
Para el item 5- Switches solicita:
“Debe permitir trabajar en el stack a través de cualquiera de sus puertos con gestión unificada.”
Solicitamos a la convocante aclarar el motivo técnico por el cual se exige que el equipo permita trabajar en stack a través de cualquiera de sus puertos, considerando que dicha característica no representa una mejora funcional ni de desempeño, convirtiendo al requerimiento en restrictivo y direccionante. Hay que destacar que la mayoría de los fabricantes utilizan puertos dedicados para stacking o chasis virtual, sin que ello afecte la gestión unificada ni el rendimiento del sistema. Dicho fabricantes cuentan con equipos de nivel datacenter que utilizan interfaces de alta velocidad específicas para stacking, precisamente para evitar degradar el rendimiento de los puertos de acceso y garantizar estabilidad del plano de control.
Es porque eso que no se observa un fundamento técnico válido que justifique exigir que “cualquiera de los puertos” sea apto para stacking, ya que dicha condición no aporta beneficios funcionales reales y limita la participación de oferentes que propongan equipos de prestaciones superiores, pero con arquitectura distinta.
En virtud del principio de igualdad de oportunidades y libre competencia establecido en la ley de contrataciones públicas, solicitamos modificar o aclarar el requerimiento de la siguiente manera:
“El switch deberá permitir apilamiento o chasis virtual con gestión unificada y redundancia total, utilizando puertos dedicados o de alta velocidad, conforme a la arquitectura definida por el fabricante.”
Esta redacción mantiene el objetivo funcional del pliego pero elimina la restricción direccionante hacia una arquitectura propietaria, permitiendo la participación de una mayor cantidad de oferentes y promoviendo la competencia leal.
Para el item 5- Switches solicita:
“Debe permitir trabajar en el stack a través de cualquiera de sus puertos con gestión unificada.”
Solicitamos a la convocante aclarar el motivo técnico por el cual se exige que el equipo permita trabajar en stack a través de cualquiera de sus puertos, considerando que dicha característica no representa una mejora funcional ni de desempeño, convirtiendo al requerimiento en restrictivo y direccionante. Hay que destacar que la mayoría de los fabricantes utilizan puertos dedicados para stacking o chasis virtual, sin que ello afecte la gestión unificada ni el rendimiento del sistema. Dicho fabricantes cuentan con equipos de nivel datacenter que utilizan interfaces de alta velocidad específicas para stacking, precisamente para evitar degradar el rendimiento de los puertos de acceso y garantizar estabilidad del plano de control.
Es porque eso que no se observa un fundamento técnico válido que justifique exigir que “cualquiera de los puertos” sea apto para stacking, ya que dicha condición no aporta beneficios funcionales reales y limita la participación de oferentes que propongan equipos de prestaciones superiores, pero con arquitectura distinta.
En virtud del principio de igualdad de oportunidades y libre competencia establecido en la ley de contrataciones públicas, solicitamos modificar o aclarar el requerimiento de la siguiente manera:
“El switch deberá permitir apilamiento o chasis virtual con gestión unificada y redundancia total, utilizando puertos dedicados o de alta velocidad, conforme a la arquitectura definida por el fabricante.”
Esta redacción mantiene el objetivo funcional del pliego pero elimina la restricción direccionante hacia una arquitectura propietaria, permitiendo la participación de una mayor cantidad de oferentes y promoviendo la competencia leal.
El requisito de "permitir trabajar en el stack a través de cualquiera de sus puertos" no es una mera preferencia arquitectónica, sino una exigencia basada en flexibilidad operativa, resiliencia y optimización de recursos en el datacenter del MTESs. Lo que el MTESS busca con esta redacción es maximizar la inversión al no depender de reserva obligatoria de puertos de alta velocidad para stacking en configuraciones con un número limitado, nos dará flexibilidad para actuar ante escenarios de contingencia y adaptación incorporación de equipos con que ya cuenta el MTESS.
Por otra parte, el requisito no prohíbe el uso de puertos dedicados de alta velocidad para stacking. Por el contrario, establece que, si la situación operativa lo requiere o si es la opción preferida del administrador, también se pueda utilizar cualquier otro puerto. La especificación busca la versatilidad máxima, no la anulación de arquitecturas específicas.
El requisito actual garantiza que la solución adjudicada ofrezca la máxima adaptabilidad para escenarios presentes y futuros, permitiendo al personal técnico del MTESS elegir la mejor topología de stacking según las necesidades del momento, sin restricciones hardware. Consideramos que esta especificación no direcciona hacia un fabricante en especifico, sino hacia un nivel de funcionalidad y versatilidad que asegure una mejor relación costo-beneficio y capacidad de adaptación a largo plazo para la institución.
Por lo expuesto, se mantiene la especificación original sin modificación.
9
CONSULTA N.º 6 – QoS
Para el item 5- Switches se solicita:
“Soporte para QoS 802.1p, IP ToS, SP y WRR. Exigido.”
Solicitamos a la convocante aclarar el motivo técnico por el cual se exige de manera literal el soporte para “SP y WRR”, en lugar de hacer referencia a los estándares o RFCs internacionales que regulan los mecanismos de Calidad de Servicio (QoS). El requerimiento tal como está redactado podría considerarse restrictivo, ya que obliga a los oferentes a presentar equipos que utilicen exactamente dichas denominaciones, cuando no existe un motivo técnico válido para imponer esos algoritmos específicos.
Fabricantes de reconocida trayectoria internacional implementan mecanismos de priorización de tráfico equivalentes o superiores, basados en las normas IEEE 802.1p, RFC 2474, RFC 2475 y RFC 2597, aunque utilicen nomenclatura distinta. Dichas variantes cumplen exactamente la misma función de priorización y gestión de colas, sin afectar en ningún modo la calidad o el desempeño de la red.
En consecuencia, no se observa una justificación técnica objetiva que sustente la exigencia de usar exclusivamente las denominaciones mencionadas, siendo que la finalidad de este punto es asegurar que el equipo ofrezca priorización de tráfico y manejo de colas ponderadas, algo que todos los equipos de clase enterprise o datacenter cumplen bajo diferentes terminologías.
En aplicación de la Ley de contrataciones públicas, que establece la obligación de redactar los pliegos de forma que garanticen la igualdad de oportunidades y no restrinjan la competencia, solicitamos modificar o aclarar el punto mencionado de la siguiente forma:
“El switch deberá soportar mecanismos de Calidad de Servicio (QoS) basados en IEEE 802.1p, con implementación de priorización y colas ponderadas o equivalentes, conforme a los estándares y RFCs internacionales vigentes.”
Esta modificación mantiene la exigencia técnica de QoS, pero elimina la restricción por denominación específica, asegurando la participación equitativa de todos los oferentes y la evaluación basada en desempeño funcional, no en terminología restrictiva.
Para el item 5- Switches se solicita:
“Soporte para QoS 802.1p, IP ToS, SP y WRR. Exigido.”
Solicitamos a la convocante aclarar el motivo técnico por el cual se exige de manera literal el soporte para “SP y WRR”, en lugar de hacer referencia a los estándares o RFCs internacionales que regulan los mecanismos de Calidad de Servicio (QoS). El requerimiento tal como está redactado podría considerarse restrictivo, ya que obliga a los oferentes a presentar equipos que utilicen exactamente dichas denominaciones, cuando no existe un motivo técnico válido para imponer esos algoritmos específicos.
Fabricantes de reconocida trayectoria internacional implementan mecanismos de priorización de tráfico equivalentes o superiores, basados en las normas IEEE 802.1p, RFC 2474, RFC 2475 y RFC 2597, aunque utilicen nomenclatura distinta. Dichas variantes cumplen exactamente la misma función de priorización y gestión de colas, sin afectar en ningún modo la calidad o el desempeño de la red.
En consecuencia, no se observa una justificación técnica objetiva que sustente la exigencia de usar exclusivamente las denominaciones mencionadas, siendo que la finalidad de este punto es asegurar que el equipo ofrezca priorización de tráfico y manejo de colas ponderadas, algo que todos los equipos de clase enterprise o datacenter cumplen bajo diferentes terminologías.
En aplicación de la Ley de contrataciones públicas, que establece la obligación de redactar los pliegos de forma que garanticen la igualdad de oportunidades y no restrinjan la competencia, solicitamos modificar o aclarar el punto mencionado de la siguiente forma:
“El switch deberá soportar mecanismos de Calidad de Servicio (QoS) basados en IEEE 802.1p, con implementación de priorización y colas ponderadas o equivalentes, conforme a los estándares y RFCs internacionales vigentes.”
Esta modificación mantiene la exigencia técnica de QoS, pero elimina la restricción por denominación específica, asegurando la participación equitativa de todos los oferentes y la evaluación basada en desempeño funcional, no en terminología restrictiva.
La combinación de SP + WRR es una arquitectura de scheduling clásica, robusta y predecible. Especificar estos algoritmos define con claridad que se requiere un sistema de colas que ofrezca tanto garantías de baja latencia (vía SP) como equidad en el reparto de ancho de banda (vía WRR).
Los oferentes deberán acreditar en su propuesta técnica (a través de documentación oficial del fabricante) que el equipo ofertado cumple con esta funcionalidad, independientemente de la terminología específica que utilice el fabricante para denominar a estos algoritmos (Prioridad Estricta o Strict Priority y Round Robin Ponderado o Weighted Round Robin).
Esta postura garantiza el resultado técnico requerido para la operación del datacenter del MTESS, mantiene un estándar de calidad claro y evaluable, y permite la participación de todos los fabricantes cuyos equipos cumplan con esta funcionalidad fundamental de QoS, respetando así los principios de igualdad y libre competencia.
Por lo expuesto, se mantiene la especificación original sin modificación.
10
Consulta N.º 8 – Alcance de la instalación y puesta en servicio de los equipos
En el Pliego de Bases y Condiciones, dentro del apartado correspondiente al plan de entrega y recepción, se indica lo siguiente:
“Los equipos serán entregados primeramente para su recepción provisoria, codificación patrimonial y verificaciones preliminares en la sede MTESS Perú (Río de Janeiro esq. Perú). Posteriormente, previo agendamiento, los equipos deberán ser trasladados e instalados en el datacenter de la DINAPI (Avda. España 323, Asunción) y/o en la sede central del MTESS (Luis A. de Herrera esq. Paraguari), a cargo del proveedor adjudicado con el acompañamiento del personal TIC designado por el MTESS para su recepción definitiva.”
Sin embargo, no se especifica en el pliego el alcance técnico exacto de la instalación requerida, lo cual genera ambigüedad al momento de dimensionar correctamente los costos y recursos asociados a los servicios a cotizar. Los equipos involucrados en el presente llamado —computadoras, servidores, storage y switches— poseen requerimientos de instalación y puesta en servicio radicalmente diferentes.
No es lo mismo una instalación física y conexión básica de equipos de escritorio, que una implementación en rack de servidores o equipamiento de red, la cual puede implicar tareas adicionales. La ausencia de una definición clara del alcance puede distorsionar los costos ofertados entre proveedores y afectar la comparabilidad de las propuestas, contraviniendo los principios de transparencia y equidad previstos en la normativa vigente.
Por lo tanto, ante la omisión de detalles sobre el alcance de instalación, sE solicita a la Convocante tenga a bien aclarar detalladamente el alcance de los servicios de instalación solicitados, especificando:
• Si se trata únicamente de entrega, desembalaje y conexión física básica, o incluye tareas adicionales (montaje en rack, conexionado de red, configuración, integración, pruebas funcionales, etc.);
• Si deberá realizarse configuración lógica o software en los servidores, storage o switches, y de ser así, hasta qué nivel de intervención técnica;
Dicha aclaración permitirá a los oferentes dimensionar correctamente la cotización, asegurando la transparencia, la igualdad de condiciones y el cumplimiento del principio de razonabilidad técnica establecido en la Ley de Contrataciones Públicas.
15-10-2025
27-10-2025
Consulta N.º 8 – Alcance de la instalación y puesta en servicio de los equipos
En el Pliego de Bases y Condiciones, dentro del apartado correspondiente al plan de entrega y recepción, se indica lo siguiente:
“Los equipos serán entregados primeramente para su recepción provisoria, codificación patrimonial y verificaciones preliminares en la sede MTESS Perú (Río de Janeiro esq. Perú). Posteriormente, previo agendamiento, los equipos deberán ser trasladados e instalados en el datacenter de la DINAPI (Avda. España 323, Asunción) y/o en la sede central del MTESS (Luis A. de Herrera esq. Paraguari), a cargo del proveedor adjudicado con el acompañamiento del personal TIC designado por el MTESS para su recepción definitiva.”
Sin embargo, no se especifica en el pliego el alcance técnico exacto de la instalación requerida, lo cual genera ambigüedad al momento de dimensionar correctamente los costos y recursos asociados a los servicios a cotizar. Los equipos involucrados en el presente llamado —computadoras, servidores, storage y switches— poseen requerimientos de instalación y puesta en servicio radicalmente diferentes.
No es lo mismo una instalación física y conexión básica de equipos de escritorio, que una implementación en rack de servidores o equipamiento de red, la cual puede implicar tareas adicionales. La ausencia de una definición clara del alcance puede distorsionar los costos ofertados entre proveedores y afectar la comparabilidad de las propuestas, contraviniendo los principios de transparencia y equidad previstos en la normativa vigente.
Por lo tanto, ante la omisión de detalles sobre el alcance de instalación, sE solicita a la Convocante tenga a bien aclarar detalladamente el alcance de los servicios de instalación solicitados, especificando:
• Si se trata únicamente de entrega, desembalaje y conexión física básica, o incluye tareas adicionales (montaje en rack, conexionado de red, configuración, integración, pruebas funcionales, etc.);
• Si deberá realizarse configuración lógica o software en los servidores, storage o switches, y de ser así, hasta qué nivel de intervención técnica;
Dicha aclaración permitirá a los oferentes dimensionar correctamente la cotización, asegurando la transparencia, la igualdad de condiciones y el cumplimiento del principio de razonabilidad técnica establecido en la Ley de Contrataciones Públicas.
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.
Por lo expuesto, se mantiene la especificación original sin modificación.