ATA DA CONSULTA TÉCNICA N.

(1)

((TITULO))ATA DA CONSULTA TÉCNICA N.º 2/2014

(PERGUNTAS E RESPOSTAS)

ATA DE REGISTRO DE PREÇOS PARA FUTURA E EVENTUAL AQUISIÇÃO DE SWITCH DE REDE ÓPTICA E SWITCH DE BORDA PARA OS ÓRGÃOS DA

ADMINISTRAÇÃO DIRETA E INDIRETA DO MUNICÍPIO DE SÃO PAULO.

Aos 29 (vinte e nove) dias do mês de abril do ano de dois mil e quatorze, às 10hs, na sede da EMPRESA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO DO MUNICÍPIO DE SÃO PAULO – PRODAM-SP S/A, a Gerência de Compras e Contratação – GFC, torna público as respostas dos questionamentos apresentados pelas empresas abaixo:

((NG))Questionamentos - HUAWEI((CL))

Prezados, apresentamos nossas considerações em nome da Huawei sobre as considerações técnicas sobre Switches.

A HUAWEI trabalha com uma completa linha de Switches desde o menor (mercado de pequenas empresas SMB), empresas médias (Mercado Pequenas e Médias) e grandes corporações.

Com o objetivo de fornecer os equipamentos com menor custo e adequados ao escopo solicitado, apresentamos nossas especificações com a finalidade de fornecer ao Município o produto adequado com o melhor preço, evitando especificações que possam encarecer o projeto. Com esse intuito apresentamos as nossas observações:

Temos um produto muito competitivo nessa linha de equipamento mas não atendemos alguns itens, somente com uma linha superior que não fica com preço em conta e mesmo assim tem item que não atendemos como o DHCP Tracker (fornecido especificamente por um fabricante) e o NSR para OSPFv3:

1.1.4. Deve possuir memória RAM no processador central de, no mínimo, 1 (um) GB (GigaByte);

Para o equipmento do lote 1 temos equipamentos com as características exigidas e com 256MB de RAM e para o equipamento do lote 2 temos 512MB.

Resposta: O ítem não será alterado.

1.1.18. Deve permitir no mínimo 20.000 (vinte mil) rotas de Ipv4 em hardware, armazenadas em CAMs localmente nos módulos de interface, considerando o somatório das capacidades individuais de cada módulo entregue na solução ofertada;

Pela característica da operação do Switch não ser de Core de rede, entendemos que 12.000 rotas IPv4 são suficientes.

Resposta: O Ítem está em avaliação interna.

1.1.26.5. Deve implementar DHCP Tracker

Funcionalidade não encontrada em todos fabricantes.

1.1.31. Deve implementar a RFC 3580 permitindo que um usuário autenticado por 802.1x seja automaticamente associado a sua respectiva VLAN;

Trabalhamos com todas funcionalidades para 802.1x e com a RFC 3579 que consideramos não ter impacto no requisitado.

(2)

1.1.66. Deve permitir a criação de no mínimo 1000 (mil) regras de ACLs de Camada 3 e 4, suportando filtragem de pacotes por endereço IP de origem e destino e por protocolo, para tráfego IPv4 e IPv6;

Para o escopo entendemos que 512 ACLs em IPv6 atendem de forma satisfatória.

1.1.79. Deve Implementar NSR (Non-stop Routing) para OSPFv3;

Não atendemos essa funcionalidade nessa família de equipamentos, entendemos que podemos oferecer produtos de CORE de rede mas encareceriam o projeto entendemos que para essa topologia podemos trabalhar sem essa funcionalidade.

1.1.81. IPv6

1.1.81.18. Serão consideradas todas as RFCs aceitas caso o fabricante comprove que

cumpre todos os requisitos da RIPE 554, disponível em português em

http://ipv6.br/download/requisitos-suporte-ipv6-ripe-554-pt.pdf

A Huawei faz parte do Forum mundial que recomenda as boas práticas no uso do IPV6, trabalhamos com RFCs mais recentes e outras com uma versão anterior em alguns casos sendo já estar no plano de atualização em futuros semestres. Entendemos que a solução deve ser atendida por IPV6 com emrpesas que tenham o certificado “IPV6 Ready Logo” e no caso da ausência da apresentação de documentação compatível nesse caso o fornecedor sim deverá comprovar o atendimento nas demais RFCs como menciona o item “1.1.81.18 que caso estejamos de acordo com o documento mencionado, as RFCs estão automaticamente aceitas. Neste documento há a seguinte menção: “Este documento recomenda que a entidade que abrir a licitação especifique que os equipamentos devem ser certificados no programa IPv6 Ready ou estar em conformidade com as RFCs listadas na seção abaixo”.

((NG))Questionamentos – DATACOM((CL)) 1. SUGESTÃO para o ITEM 1.1.7

1.1.7. Deve possuir, no mínimo, 2 (duas) portas SFP+, ou XFP, populadas com portas óticas de 10 (dez) Gbps monomodo, acompanhadas de cordão óptico de, no mínimo, 2 (dois) metros, com terminação em conectores do tipo LC monomodo;

Recomenda-se incluir nos acessórios do edital módulos com outras opções de alcance. Há opções de mercado de 40km e 80km para os principais fornecedores do setor. Também é muito importante considerar a opção de modelos 1000Base-BX (monomodo 1310/1550nm até 20km e/ou 60km), 10BASE-BX (monomodo, 1270/1330nm até 20km e/ou 60km). Módulos 1000BASE-BX e 10BASE-BX são ditos "bidirecionais" ou "monofibra" já que permitem a construção de enlaces com apenas uma fibra. Pode-se dobrar a capacidade do link usando um par de fibra ao fazer uso destes módulos, cujo custo não é tão superior. Além disso, links com módulos Bidirecionais não causam falhas de link "unidirecionais" como pode ocorre com os links simplex quando rompe a fibra.

2. SUGESTÃO para o ITEM 1.1.10

1.1.10. Deve possuir fonte de alimentação interna ao equipamento, que opere com tensões de entrada entre 100 e 240VAC e suporte frequência de 60 Hz nominais (+ ou – 5%)

(3)

Switches para Rede Metro no porte solicitado nesta Especificação comumente são alimentados em DC, há alguns modelos que suportam AC e DC. Uma opção que costuma trazer melhor competitividade é solicitar que produto possa ser alimentado tanto em AC quanto DC. Para isso, permite-se que seja fornecida uma fonte externa AC/DC para os POPs onde se disponibilize apenas alimentação AC.

Com base no que foi exposto, sugerimos que o texto seja alterado para:

1.1.10. Deve possuir fonte de alimentação interna ao equipamento, que opere com tensões de entrada entre 100 e 240VAC com freqüência de 60 Hz nominais (+ ou – 5%) e 48-60VDC.

1.1.11. Deve possuir fonte de energia interna redundante;

O item 1.1.11 fala sobre as fontes de energia que deverão ser internas e redundantes, porém não trata de uma característica bastante relevante de que as fontes deverão ser modulares e “hot-swappable”, permitindo com que a substituição de uma fonte defeituosa possa ser feita sem interromper o funcionamento do switch.

1.1.11. Deve possuir fontes de energia que sejam internas, modulares e permitam sua substituição sem necessidade de parar o equipamento (hot swappable).

4. ESCLARECIMENTO sobre o ITEM 1.1.15

1.1.15. Deve implementar funcionalidade de espelhamento de tráfego TX e RX,permitindo que as portas de origem e destino estejam em qualquer ponto da pilha;

A redação do item 1.1.15 inclui a frase “permitindo que as portas de origem e destino estejam em qualquer ponto da pilha;”. A inclusão do termo “pilha” pode ser interpretada por algum fornecedor como requisito de que os equipamentos sejam empilháveis. Todavia, na especificação não há nenhum item que trate dos requisitos mínimos funcionais para a função empilhamento. Baseado em outros processos licitatórios que a DATACOM tem participado, recomendamos que o texto seja readequado para evitar impetração de recursos ou diligências durante o processo de aceitação/homologação do vencedor.

Pelo que foi exposto anteriormente, recomendamos que a redação seja alterada para: 1.1.15. Deve implementar funcionalidade de espelhamento de tráfego TX e RX;

Resposta: O conteúdo do Ítem será alterado.

5. ESCLARECIMENTO sobre os ITENS 1.1.16, 1.1.18, 1.1.66 e 1.1.68

Os itens 1.1.16, 1.1.18, 1.1.66 e 1.1.68 especificam capacidades para MAC, rotas (IPv4/IPv6), ACLs e VLANs, porém não define claramente que estas capacidades precisam ser atendidas simultaneamente. Por isso, para evitar que sejam adquiridos equipamentos que não garantam atingimento destas capacidades simultaneamente e com performance, recomendamos que seja especificado que estas capacidades devem ser atingidas simultaneamente e sem degradação de performance.

Face ao que foi exposto, recomendamos a inclusão do seguinte item:

As capacidades de MACs, rotas (IPv4 e IPv6), ACLs e VLANs deverão ser atendidos simultaneamente nos valores mínimos solicitados e sem provocar degradação de performance do equipamento.

(4)

6. SOLICITAÇÃO para o ITEM 1.1.18

O item 1.1.18 está demandando uma capacidade de rotas IPv4 que faz com que os equipamentos a ser ofertados sejam de um porte muito superior e restritivo ao processo de disputa entre os potenciais fornecedores. Considerando as funcionalidades solicitadas e o porte de equipamentos disponíveis no portfólio dos principais fornecedores, o valor de capacidade típico para Switch de Rede Ótica é 12.000 rotas IPv4 e 6.000 IPv6. Também é altamente relevante que a capacidade de rotas seja da FIB (Forward Information Based), uma

vez que tem equipamentos que só oferecem este valor de rotas na RIB (Routing Information Based), não garantindo disponibilidade das rotas em HW.

Desta forma, para haver mais competitividade e um custo mais adequado para a administração pública, a DATACOM solicita que o item seja alterado para:

1.1.18. Deve permitir no mínimo 12.000 (doze mil) rotas de IPv4 e 6.000 (seis mil) rotas IPv6 em hardware (FIB), armazenadas em CAMs, garantindo a performance para encaminhamento de pacotes IPv4 e/ou IPv6;

7. SOLICITAÇÃO para o ITEM 1.1.26.5 1.1.26.5 DHCP Tracker

Esta funcionalidade não é comum encontrar entre os principais fabricantes de switches para rede Metro. Essa terminologia "DHCP Tracker" foi encontrada apenas em um fabricante, o que provavelmente gerará questionamentos durante a publicação do edital. Face ao exposto, solicitamos que o item seja retirado da especificação.

1.1.30. Deve implementar IEEE 802.3 ad (link aggregation), permitindo a criação de, no mínimo, 4 LAGs com 04 portas por LAG;

Considerando que a especificação deste equipamento incluir demanda por porta 1Gbps e 10Gbps, entendemos que os links agregados (LAGs) especificados no item 1.1.30 deverem possibilitar a agregação de portas 1Gbps e 10Gbps simultaneamente no mesmo LAG. Nosso entendimento está correto?

Caso nosso entendimento esteja correto, recomendamos que o item seja alterado para: 1.1.30. Deve implementar IEEE 802.3 ad (link aggregation), permitindo a criação de,

no mínimo, 4 LAGs com 04 portas por LAG. Deverá ser possível fazer agregação de links incluindo simultaneamente portas 1Gbps e 10Gbps no mesmo grupo.

Resposta: O entendimento está incorreto. O texto será alterado deixando mais claro a agregação de portas apenas com a mesma velocidade.

1.1.34. Deve implementar os seguintes protocolos de roteamento Ipv4 em todas as suas interfaces: OSPF, BGP4 e OSPFv3.

Para não gerar dúvidas quanto aos protocolos de roteamento, sugerimos a seguinte alteração na especificação técnica:

1.1.34. Deve implementar os seguintes protocolos de roteamento em todas as suas interfaces: OSPF (IPv4), BGP4 (IPv4/IPv6) e OSPFv3 (IPv6).

(5)

1.1.36. Deve ter suporte a Radius Authentication, Authorization e Accounting

Para manter a coerência com demais itens solicitados sobre protocolos de controle de acesso na especificação, onde é solicitado TACACS, indicamos a solicitação de RADIUS ou TACACS para esse item, alterando para:

1.1.36. Deve ter suporte a Radius/Tacacs Authentication, Authorization e Accounting

Resposta: O ítem não será alterado. A Prodam utiliza ambos os protocolos de AAA

1.1.49. Deve Possuir 1 (uma) porta RS-232C (DB-9) ou Ethernet (RJ-45) para fins de gerenciamento via console.

Entendemos que a solicitação é de uma porta RS-232C, então é incorreto dizer que a interface RJ-45 é Ethernet.

Com isso sugerimos a alteração da especificação para:

1.1.49. Deve Possuir 1 (uma) porta RS-232C (conector DB-9 ou RJ-45) para fins de gerenciamento via console).

12. SUGESTÃO para o ITEM 1.1.55 1.1.55. Deve implementar Multicast IPv4. Sugerimos a alteração da especificação para: 1.1.55. Deve implementar Multicast IPv4 e IPv6.

1.1.60. Deve suportar Inbound Rate Limiting;

O item 1.1.60 especifica o recurso de Rate Limiting, porém especifica a necessidade de implementar apenas no sentido “Inbound” (entrada) e não sobre o sentido “Outbound” (saída). A DATACOM entende que é importante incluir na redação que o recurso possa estar disponível em ambas as direções. Também, é importante especifica a granularidade mínima que deverá ser suportada para a configuração da taxa de limitação por porta. Equipamentos de mercado dos principais fornecedores que atendem a esta especificação usualmente suportam granularidade de 64kbps para configuração de Rate Limiting.

Diante disso, recomendamos que o item 1.1.60 seja alterado para:

1.1.60. Deve implementar Rate Limiting “Inbound” (entrada) e “Outbound” (saída) por porta

e permitindo configuração de taxa com granularidade mínima de 64kbps,

independentemente da velocidade de operação da porta (1Gbps ou 10Gbps);

1.1.64. Deve ser possível informar, por porta do switch, a quantidade de endereços MACs que podem ser aprendidos;

Em associação ao controle de MAC já especificado no item 1.1.64, sugerimos que o switch tenha a capacidade de desabilitar e limitar aprendizagem de MAC por porta e VLAN. Esse tipo de controle fornece ao administrador de rede, recursos para controlar o número de dispositivos de rede ligados a uma porta ou VLAN, trazendo mais segurança e controle a rede. Em redes que devem prover serviços de conectividade LAN-to-LAN, intencionalmente ou acidentalmente, o número de endereços MAC pode ser aumentado drasticamente, de

(6)

tal forma que a rede perde a capacidade de encaminhamento e portanto desempenho. Sendo assim, com o intuito de adicionar mais facilidades de segurança a equipamento, sugerimos a inclusão do seguinte item:

1.1.64. Deve ser possível informar, por porta e VLAN do switch, a quantidade de endereços MACs que podem ser aprendidos;

1.1.66. Deve permitir a criação de no mínimo 1000 (mil) regras de ACLs de Camada 3 e 4, suportando filtragem de pacotes por endereço IP de origem e destino e por protocolo, para tráfego IPv4 e IPv6;

Buscando garantir que o equipamento a ser ofertado implementem ACLs de Camada 3 e 4 com performance, é altamente relevante deixar claro que este recurso seja implementado em HW, já que alguns equipamentos implementam uma capacidade de ACL alta apenas em software. O problema da ACL ser executa em software é que isso causa baixa performance, além de poder degradar o funcionamento do equipamento em condições de altos throughputs.

Diante do exposto, sugerimos que o item 1.1.66 seja alterado para:

1.1.66. Deve permitir a criação de no mínimo 1000 (mil) regras de ACLs de Camada 3 e 4, suportando filtragem de pacotes por endereço IP de origem e destino e por protocolo, para tráfego IPv4 e IPv6. As ACLs deverão ser implementadas em HW para garantir performance e não causem degradação de funcionamento do equipamento.

16. Sugestão para o ITEM 1.1.67

1.1.67. Deve suportar Broadcast Suppression, permitindo configurar valores individuais de supressão por porta;

O item 1.1.67 trata da especificação de “Storm Control” para pacotes do tipo Broadcast. Todavia, sugerimos que o Storm Control seja mais amplo e não apenas para tráfego broadcast. O Storm control deve atuar quando ocorre o “flooding“ de pacotes na rede, criando um tráfego excessivo e portanto degrando o desempenho do conjunto de equipamentos. Apesar de broadcast storm ser mais comum, atenção aos tráfegos unicast e multicast também deve ocorrer a fim de não se ter pontos de falha de segurança na rede. Os problemas de storm numa rede, não estão apenas associados a ataques maliciosos. Ele podem ocorrer devido a falhas de configuração e/ou protocolo, que podem levar a loops. Para esses situações, o Storm Control pode atuar como proteção. Baseado nisso, sugerimos que a redação desse subitem seja mudado, a fim de englobar os tráfegos unicast e multicast.

Diante do que foi exposto, recomendamos que seja incluído item conforme abaixo:

Implementar controle e contenção de tráfegos broadcast, multicast e unicast, que degradam o desempenho do switch (storm control), permitindo configurar limites com granularidade mínima de 64kbps.

1.1.79. Deve Implementar NSR (Non-stop Routing) para OSPFv3;

Entendemos que essa funcionalidade se aplica apenas para equipamentos que possuam múltiplos processadores.

Quando NSR é usado, os demais dispositivos da rede não tomam conhecimento de qualquer evento que tenha ocorrido no switch que apresentou falha. Todas as informações

(7)

necessárias para continuar o roteamento continuam funcionando no processador redundante imediatamente após o evento.

Por outro lado, com a funcionalidade Graceful Restart, os demais dispositivos da rede são informados que devem “atrasar” as informações de alterações na rede porque algum evento crítico ocorreu. Esse “atraso” deve ocorrer por determinado tempo, até que os equipamentos sejam capazes de reestabelecer a relação de vizinhança/adjacência, enquanto isso continuam transmitindo informações ao demais elementos, sem parada de encaminhamento do tráfego. O Graceful Restart (GR) está definido pelo IETF para os protocolos OSPF, ISIS, BGP e LDP para garantir interoperabilidade entre fabricantes. Dado que os equipamentos que estão sendo licitados interagirão com equipamentos de Rede Metro e/ou Core os quais deverão suportar Graceful Restart, entendemos que é relevante para esta especificação garantir que os switches suportem “Graceful Restart Helper Mode” conforme estabelecido nas RFCs 3623, 4724 para IPv4 e IPv6.

Logo, recomendamos que o item seja alterado para:

1.1.79. Deve Implementar Graceful Restart (Helper Mode) para OSPF/BGP (para IPv4 e IPv6) segundo RFCs 3623 e 4724;

18. SOLICITAÇÃO para os ITENS 1.1.81.9, 1.1.81.11, 1.1.81.14 e 1.1.81.17 1.1.81.9. Seleção de Endereço Padrão (Default Address Selection, RFC3484). 1.1.81.11. SLAAC [RFC4862].

1.1.81.14. MIBs SNMP para IP (SNMP MIBs for IP, RFC4293) "Encaminhamento" (Forwarding, RFC4292) e DiffServ [RFC3289].

1.1.81.17. Filtragem UPnP (UPnP filtering).

De acordo com o RIPE 554, os requisitos relativos a IPv6 podem ser divididos em 2 categorias: os “obrigatórios" e os "opcionais”. Segundo o nic.br, através da divulgação do RIPE já mencionado, as RFCs exigidas nos itens 1.1.81.9, 1.1.81.11, 1.1.81.14 e 1.1.81.17 não são obrigatórias para o uso em switches. A inclusão desses requisitos pode diminuir a competitividade e por consequência o aumento do preço de aquisição. É nosso entendimento que requisitos não essenciais não devam influenciar nos custos de aquisição. Pelo que foi exposto anteriormente, sugerimos que estes itens sejam retirados da especificação técnica.

19. SUGESTÃO para TROUBLESHOOTING

As ferramentas de troubleshooting e monitoramento de redes L3 são amplamente divulgadas e conhecidas (e.g. ping, traceroute, etc). Para redes Metro Ethernet ou Switches de Acesso/Borda essa ferramentas podem ser ineficientes ou insuficientes. Para cobrir essa falta,

o IEEE e o ITU-T especificaram algumas normas que recomendamos estar presentes em redes projetadas para ter grandes níveis de disponibilidade. Sendo assim, sugerimos os protocolos OAM CFM IEEE 802.1ag, OAM EFM 802.3ah) e ITU-T Y.1731. Basicamente, essas normas disponibilizam alguns protocolos e ferramentas equivalentes existentes em L3 para o ambiente Ethernet, tais como:

Teste de conectividade; Medição de tráfego;

Medição de desempenho da rede, tais como Latência, Jitter e perda de pacotes.

Os principais fabricantes de switches ethernet para redes de acesso implementam esses protocolos padronizados em seus equipamentos, portanto, não devem alterar o custo de aquisição, mas agregarão funcionalidades que ajudarão na administração da rede e no

(8)

monitoramento dos seus índices de serviço (SLA). Sendo assim, sugerimos a inclusão dos seguintes itens:

Implementar Ethernet Link OAM IEEE 802.3ah; Implementar Ethernet CFM IEEE 802.1ag;

Implementar Ethernet Y.1731 com recursos em MIB para exportação dos contadores de monitoramento de desempenho, tais como packet loss e jitter;

Resposta: A Sugestão está sendo avaliada

20. SUGESTÃO para QoS

No termo de referência não foi especificado a quantidade mínima de filas de QoS por porta que deverão estar disponíveis para configuração de QoS. Equipamentos de porte compatíveis com esta Especificação disponibilizam 8 filas de QoS por porta. Por isso, a inclusão deste requisito não implicará em aumento de custos, enquanto que garante à administração pública que o equipamento fornecido disponibilize este recurso tão importante para implementação com qualidade dos serviços de VOZ, DADOS, VÍDEO, NETWORK CONTROL, MANAGEMENT, BEST EFFORT.

Face ao exposto, sugerimos a inclusão de item conforme abaixo:

Implementar 8 filas de QoS por porta, independentemente da taxa de operação da porta ser 1Gbps ou 10Gbps.

21. SUGESTÕES para MPLS

Com a intenção de contribuir com a Prodam na construção de uma rede convergente, que suporte os mais diferentes serviços existentes e que possua a capacidade de absorver a evolução futura desses serviços, sugerimos que seja considerada a inclusão de funcionalidades MPLS ao switch Tipo 1 deste edital.

Podemos citar os seguintes benefícios quando se implanta redes baseadas em MPLS em redes LAN:

Decisão de encaminhamento é feita na borda da rede

Solução de camada 3, portanto “loop free”, evitando grandes esforços e contratempos com a configuração e administração de protocolos tais como STP e MSTP, reduzindo a complexidade da rede

Suporta serviço de VPN “Agnóstico ao Protocolo”

A utilização de VPNs L2 podem criar grandes domínios L2 sem as desvantagens das redes L2 tradicionais, independentemente da localização geográfica

A utilização de VPNs L3 permitem a criação de diversos domínios administrativos Habilidade de permitir múltiplos serviços

Modelo orientado a conexão permite escolha de melhores caminhos, resultando no provimento de uma melhor QoS

Altamente escalável sem aumentar os esforços de administração e gerência

Tem a capacidade de oferecer proteção sub-50ms em caso de eventos de falha, o que é muito importante em rede com tráfego de voz/vídeo ou de “missão-crítica”, contra os mais de 15 segundos dos protocolos de proteção a loop tradicionais

O investimento necessários para habilitar o MPLS oferece um retorno significativo na maioria das aplicações baseadas em escala e desempenho. A economia conseguida com a implantação de serviços convergentes (e.g VoIP) são possíveis devido ao ganho em desempenho da rede para atender aos requisitos de aplicações cada vez mais exigentes. Além desses ganhos já citados, temos ainda aquele conseguido com a operação da rede, em virtude da diminuição da complexidade e aumentos da confiabilidade e resiliência.

(9)

Sendo assim, sugerimos a inclusão dos seguintes itens: Implementar RFC 3031 MPLS Architecture.

Implementar RFC 3032 MPLS Label Stack Encoding. Implementar RFC 5036 LDP Specification.

Implementar RFC 3270 MPLS Support of Differentiated Services.

Implementar RFC 2702 Requirements for Traffic Engineering Over MPLS. Implementar RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels. Implementar RFC 4664 - Framework for Layer 2 Virtual Private Networks (L2VPNs).

Implementar RFC 4665 - Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks.

Implementar VPLS com sinalização LDP - RFC 4762 - Virtual Private LAN Service Using Label Distribution Protocol (LDP) Signaling.

22. SUGESTÕES de Inclusão

A fim de facilitar a operação dos equipamentos, a interoperabilidade, o gerenciamento dos equipamentos, o suporte técnico, a gestão de sobressalentes e o treinamento, sugerimos incluir o seguinte item na especificação técnica:

Todos os equipamentos propostos, em ambos os lotes, deverão ser do mesmo fabricante. Visando garantir que o equipamento atenda a normas técnicas nacionais e internacionais, solicitamos que sejam incluídos os seguintes itens na especificação técnica:

Os equipamentos ofertados deverão ter certificação Anatel, de acordo com os procedimentos regulamentados pela Resolução nº 242/2000. Tais certificados devem ser apresentados junto com a proposta.

Os equipamentos ofertados deverão estar em conformidade com as normas MEF 9 e 14 (CE 1.0).

Visando garantir que o equipamento ofertado não esteja em final de vida, solicitamos que seja incluído o seguinte item na especificação técnica:

O produto ofertado não deve ter “end-of-sales” ou “end-of-life” inferior a 02 (dois) anos na data do pregão.

23. ESCLARECIMENTO

A DATACOM apoia as ações de promoção da tecnologia IPv6, bem como a sua implantação. Prova disso é que nos últimos anos tem capacitado seus produtos para atender esta demanda, com especial foco e prioridade nos protocolos essenciais para operação da rede. Os produtos fornecidos para projetos estratégicos do governo como PNBL e Cidades Digitais, para os quais a DATACOM foi adjudicada como fornecedora, estão capacitados a atender as demandas de migração para IPv6. Funcionalidades secundárias e não essenciais continuam sendo priorizadas no roadmap de desenvolvimento de produto, como é o caso das funcionalidades abaixo:

1.1.81.2. Filtragem DHCPv6 (DHCPv6 filtering, RFC3315)

1.1.81.3. Filtragem de Anúncio de Roteador (RA) (Router Advertisement (RA) filtering,RFC4862).

1.1.81.4. Inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection, RFC4861).

1.1.81.6. Investigação e filtragem de Detecção de Endereço Repetido (Duplicate Address Detection [DAD, RFC4429] snooping and filtering).

Itens não essenciais limitam a competitividade e, por consequência, encarecem desnecessariamente o processo de aquisição. Além disso, os itens citados acima, serão

(10)

disponibilizados em breve e não há justificativas para a não aceitação de fornecimento dela após o certame. Pela resolução CGI.br/RES/2013/033, do comitê gestor da internet no Brasil, fica claro que não há consenso sobre cronogramas e metas para a implantação do IPv6 no Brasil. Sendo assim, reforçamos que sejam definidos/permitidos prazos para os fabricantes ajustem seus produtos a determinadas especificações do IPv6 e que ao mesmo tempo atendam aos cronogramas de migração do PRODAM.

LOTE 2

1. SOLICITAÇÃO para o ITEM 2.7

2.7. Deve possuir, no mínimo, 4 (duas) portas SFP+, ou XFP, populadas com 2 (duas) portas óticas de 1 (um) Gbps monomodo, acompanhadas de cordão óptico de, no mínimo, 2 (dois) metros, com terminação em conectores do tipo LC monomodo e 2 (duas) portas óticas de 10 (dez) Gbps monomodo, acompanhadas de cordão óptico de, no mínimo, 2 (dois) metros, com terminação em conectores do tipo LC monomodo;

Para deixar claro que o solicitado são 2 (duas) portas 10Gbps e 2 (duas) portas 1Gbps óticas, sugerimos a alteração no texto, conforme abaixo:

2.7. Deve possuir, no mínimo, 2 (duas) portas SFP óticas de 1 (um) Gbps monomodo, acompanhadas de cordão óptico de, no mínimo, 2 (dois) metros, com terminação em conectores do tipo LC monomodo e 2 (duas) portas óticas SFP+ ou XFP de 10 (dez) Gbps monomodo, acompanhadas de cordão óptico de, no mínimo, 2 (dois) metros, com terminação em conectores do tipo LC monomodo;

Além deste ponto, recomenda-se incluir nos acessórios do edital módulos com outras opções de alcance. Há opções de mercado de 40km e 80km para os principais fornecedores do setor. Também é muito importante considerar a opção de modelos 1000Base-BX (monomodo 1310/1550nm até 20km e/ou 60km), 10BASE-BX (monomodo, 1270/1330nm até 20km e/ou 60km). Módulos 1000BASE-BX e 10BASE-BX são ditos "bidirecionais" ou "monofibra" já que permitem a construção de enlaces com apenas uma fibra. Pode-se dobrar a capacidade do link usando um par de fibra ao fazer uso destes módulos, cujo custo não é tão superior. Além disso, links com módulos Bidirecionais não causam falhas de link "unidirecionais" como pode ocorre com os links simplex quando rompe a fibra.

2. SUGESTÃO para o ITEM 2.10

2.10. Deve possuir fonte de alimentação interna ao equipamento, que opere com tensões de entrada entre 100 e 240VAC e suporte frequência de 60 Hz nominais (+ ou – 5%) Switches para Rede Metro no porte solicitado nesta Especificação comumente são alimentados em DC, há alguns modelos que suportam AC e DC. Uma opção que costuma trazer melhor competitividade é solicitar que produto possa ser alimentado tanto em AC quanto DC.

Para isso, permite-se que seja fornecida uma fonte externa AC/DC para os POPs onde se disponibilize apenas alimentação AC.

2.10. Deve possuir fonte de alimentação interna ao equipamento, que opere com tensões de entrada entre 100 e 240VAC com freqüência de 60 Hz nominais (+ ou – 5%) e 48-60VDC.

(11)

2.11. Deve possuir fonte de energia interna redundante;

O item 2.11 fala sobre as fontes de energia que deverão ser interna e redundantes, porém não trata de uma característica bastante relevante de que as fontes deverão ser “slotaveis” e “hot-swappable”, permitindo com que a substituição de uma fonte defeituosa possa ser feita sem interromper o funcionamento do switch.

2.11. Deve possuir fontes de energia que sejam internal, “slotaveis” e permitam sua substituição sem necessidade de parar o equipamento (hot swappable).

4. ESCLARECIMENTO sobre o ITEM 2.15

2.15. Deve implementar funcionalidade de espelhamento de tráfego TX e RX, permitindo que as portas de origem e destino estejam em qualquer ponto da pilha;

A redação do item 2.15 inclui a frase “permitindo que as portas de origem e destino estejam em qualquer ponto da pilha;”. A inclusão do termo “pilha” pode ser interpretada por algum fornecedor como requisito de que os equipamentos sejam empilháveis. Todavia, na especificação não há nenhum item que trate dos requisitos mínimos funcionais para a função empilhamento. Baseado em outros processos licitatórios que a DATACOM tem participado, recomendamos que o texto seja readequado para evitar impetração de recursos ou diligências durante o processo de aceitação/homologação do vencedor.

Pelo que foi exposto anteriormente, recomendamos que a redação seja alterada para: 2.15. Deve implementar funcionalidade de espelhamento de tráfego TX e RX;

Resposta: O conteúdo do item será alterado.

5. SOLICITAÇÃO para o ITEM 2.18

2.18. Deve permitir no mínimo 5.000 (vinte mil) rotas de Ipv4 em hardware, armazenadas em CAMs localmente nos módulos de interface, considerando o somatório das capacidades individuais de cada módulo entregue na solução ofertada;

O item 2.18 está demandando a capacidade de rotas IPv4, porém não está especificando a quantidade de rotas IPv6 que deverão ser suportadas. Considerando as funcionalidades solicitadas e o porte de equipamentos disponíveis no portfólio dos principais fornecedores, o valor de capacidade típico para Switch de Rede Ótica é usualmente metade da capacidade IPv4. Também é altamente relevante que a capacidade de rotas seja da FIB (Forward Information Based), uma vez que tem equipamentos que só oferecem este valor de rotas na RIB (Routing Information Based), não garantindo disponibilidade das rotas em HW.

Desta forma, para haver mais competitividade e um custo mais adequado para a administração pública, a DATACOM solicita que o item seja alterado para:

2.18. Deve permitir no mínimo 5.000 (cinco mil) rotas de IPv4 e 2.500 (duas mil e quinhentas) rotas IPv6 em hardware (FIB), armazenadas em CAMs, garantindo a performance para encaminhamento de pacotes IPv4 e/ou IPv6;

6. ESCLARECIMENTO sobre os ITENS 2.16, 2.18, 2.66 e 2.68

Os itens 2.16, 2.18, 2.66 e 2.68 especificam capacidades para MAC, rotas (IPv4/IPv6), ACLs e VLANs, porém não define claramente que estas capacidades precisam ser atendidas simultaneamente. Por isso, para evitar que sejam adquiridos equipamentos que não garantam atingimento destas capacidades simultaneamente e com performance,

(12)

recomendamos que seja especificado que estas capacidades devem ser atingidas simultaneamente e sem degradação de performance.

Face ao que foi exposto, recomendamos a inclusão do seguinte item:

As capacidades de MACs, rotas (IPv4 e IPv6), ACLs e VLANs deverão ser atendidos simultaneamente nos valores mínimos solicitados e sem provocar degradação de performance do equipamento.

7. SOLICITAÇÃO para o ITEM 2.26.5 2.26.5 DHCP Tracker

Esta funcionalidade não é comum encontrar entre os principais fabricantes de switches para rede Metro. Essa terminologia "DHCP Tracker" foi encontrada apenas em um fabricante, o que provavelmente gerará questionamentos durante a publicação do edital. Face ao exposto, solicitamos que o item seja retirado da especificação.

2.30. Deve implementar IEEE 802.3 ad (link aggregation), permitindo a criação de, no mínimo, 4 LAGs com 04 portas por LAG;

Considerando que a especificação deste equipamento incluir demanda por porta 1Gbps e 10Gbps, entendemos que os links agregados (LAGs) especificados no item 2.30 deverem possibilitar a agregação de portas 1Gbps e 10Gbps simultaneamente no mesmo LAG. Nosso entendimento está correto?

Caso nosso entendimento esteja correto, recomendamos que o item seja alterado para: 2.30. Deve implementar IEEE 802.3 ad (link aggregation), permitindo a criação de,

no mínimo, 4 LAGs com 04 portas por LAG. Deverá ser possível fazer agregação de links incluindo simultaneamente portas 1Gbps e 10Gbps no mesmo grupo.

Resposta: O entendimento está incorreto. O texto será alterado deixando mais claro a agregação de portas apenas com a mesma velocidade.

2.34. Deve implementar os seguintes protocolos de roteamento Ipv4 em todas as suas interfaces: OSPF, BGP4 e OSPFv3.

Para não gerar dúvidas quanto aos protocolos de roteamento, sugerimos a seguinte alteração na especificação técnica:

2.34. Deve implementar os seguintes protocolos de roteamento em todas as suas interfaces: OSPF (IPv4), BGP4 (IPv4/IPv6) e OSPFv3 (IPv6).

SUGESTÃO para o ITEM 2.36

2.36. Deve ter suporte a Radius Authentication, Authorization e Accounting

Para manter a coerência com demais itens solicitados sobre protocolos de controle de acesso na especificação, onde é solicitado TACACS, indicamos a solicitação de RADIUS ou TACACS para esse item, alterando para:

2.36. Deve ter suporte a Radius/Tacacs Authentication, Authorization e Accounting

1.1.49. Deve Possuir 1 (uma) porta RS-232C (DB-9) ou Ethernet (RJ-45) para fins de gerenciamento via console.

(13)

Entendemos que a solicitação é de uma porta RS-232C, então é incorreto dizer que a interface RJ-45 é Ethernet.

Com isso sugerimos a alteração da especificação para:

1.1.49. Deve Possuir 1 (uma) porta RS-232C (conector DB-9 ou RJ-45) para fins de gerenciamento via console).

1.1.55. Deve implementar Multicast IPv4. Sugerimos a alteração da especificação para: 1.1.55. Deve implementar Multicast IPv4 e IPv6.

2.60. Deve suportar Inbound Rate Limiting;

O item 2.60 especifica o recurso de Rate Limiting, porém especifica a necessidade de implementar apenas no sentido “Inbound” (entrada) e não sobre o sentido “Outbound” (saída). A DATACOM entende que é importante incluir na redação que o recurso possa estar disponível em ambas as direções. Também, é importante especifica a granularidade mínima que deverá ser suportada para a configuração da taxa de limitação por porta. Equipamentos de mercado dos principais fornecedores que atendem a esta especificação usualmente suportam granularidade de 64kbps para configuração de Rate Limiting.

Diante disso, recomendamos que o item 2.60 seja alterado para:

2.60. Deve implementar Rate Limiting “Inbound” (entrada) e “Outbound” (saída) por porta e permitindo configuração de taxa com granularidade mínima de 64kbps, independentemente da velocidade de operação da porta (1Gbps ou 10Gbps);

2.64. Deve ser possível informar, por porta do switch, a quantidade de endereços MACs que podem ser aprendidos;

Em associação ao controle de MAC já especificado no item 2.64, sugerimos que o switch tenha a capacidade de desabilitar e limitar aprendizagem de MAC por porta e VLAN. Esse tipo de controle fornece ao administrador de rede, recursos para controlar o número de dispositivos de rede ligados a uma porta ou VLAN, trazendo mais segurança e controle a rede. Em redes que devem prover serviços de conectividade LAN-to-LAN, intencionalmente ou acidentalmente, o número de endereços MAC pode ser aumentado drasticamente, de tal forma que a rede perde a capacidade de encaminhamento e portanto desempenho. Sendo assim, com o intuito de adicionar mais facilidades de segurança a equipamento, sugerimos a inclusão do seguinte item:

2.64. Deve ser possível informar, por porta e VLAN do switch, a quantidade de endereços MACs que podem ser aprendidos;

2.66. Deve permitir a criação de no mínimo 1000 (mil) regras de ACLs de Camada 3 e 4, suportando filtragem de pacotes por endereço IP de origem e destino e por protocolo, para tráfego IPv4 e IPv6;

Buscando garantir que o equipamento a ser ofertado implementem ACLs de Camada 3 e 4 com performance, é altamente relevante deixar claro que este recurso seja implementado

(14)

em HW, já que alguns equipamentos implementam uma capacidade de ACL alta apenas em software. O problema da ACL ser executa em software é que isso causa baixa performance, além de poder degradar o funcionamento do equipamento em condições de altos throughputs.

Diante do exposto, sugerimos que o item 2.66 seja alterado para:

2.66. Deve permitir a criação de no mínimo 1000 (mil) regras de ACLs de Camada 3 e 4, suportando filtragem de pacotes por endereço IP de origem e destino e por

protocolo, para tráfego IPv4 e IPv6. As ACLs deverão ser implementadas em HW para garantir performance e não causem degradação de funcionamento do equipamento

15. Sugestão para o ITEM 2.67

2.67. Deve suportar Broadcast Suppression, permitindo configurar valores individuais de supressão por porta;

O item 2.67 trata da especificação de “Storm Control” para pacotes do tipo Broadcast. Todavia, sugerimos que o Storm Control seja mais amplo e não apenas para tráfego broadcast. O Storm control deve atuar quando ocorre o “flooding“ de pacotes na rede, criando um tráfego excessivo e portanto degrando o desempenho do conjunto de equipamentos. Apesar de broadcast storm ser mais comum, atenção aos tráfegos unicast e multicast também deve ocorrer a fim de não se ter pontos de falha de segurança na rede. Os problemas de storm numa rede, não estão apenas associados a ataques maliciosos. Ele podem ocorrer devido a falhas de configuração e/ou protocolo, que podem levar a loops. Para esses situações, o Storm Control pode atuar como proteção. Baseado nisso, sugerimos que a redação desse subitem seja mudado, a fim de englobar os tráfegos unicast e multicast.

Diante do que foi exposto, recomendamos que seja incluído item conforme abaixo:

2.67. Implementar controle e contenção de tráfegos broadcast, multicast e unicast, que degradam o desempenho do switch (storm control), permitindo configurar limites com granularidade mínima de 64kbps.

2.79. Deve Implementar NSR (Non-stop Routing) para OSPFv3;

Entendemos que essa funcionalidade se aplica apenas para equipamentos que possuam múltiplos processadores.

Quando NSR é usado, os demais dispositivos da rede não tomam conhecimento de qualquer evento que tenha ocorrido no switch que apresentou falha. Todas as informações necessárias para continuar o roteamento continuam funcionando no processador redundante imediatamente após o evento.

Por outro lado, com a funcionalidade Graceful Restart, os demais dispositivos da rede são informados que devem “atrasar” as informações de alterações na rede porque algum evento crítico ocorreu. Esse “atraso” deve ocorrer por determinado tempo, até que os equipamentos sejam capazes de reestabelecer a relação de vizinhança/adjacência, enquanto isso continuam transmitindo informações ao demais elementos, sem parada de encaminhamento do tráfego. O Graceful Restart (GR) está definido pelo IETF para os protocolos OSPF, ISIS, BGP e LDP para garantir interoperabilidade entre fabricantes. Dado que os equipamentos que estão sendo licitados interagirão com equipamentos de Rede Metro e/ou Core os quais deverão suportar Graceful Restart, entendemos que é relevante para esta especificação garantir que os switches suportem “Graceful Restart Helper Mode” conforme estabelecido nas RFCs 3623, 4724 para IPv4 e IPv6.

(15)

Logo, recomendamos que o item seja alterado para:

2.79. Deve Implementar Graceful Restart (Helper Mode) para OSPF/BGP (para IPv4 e IPv6) segundo RFCs 3623 e 4724;

17. SOLICITAÇÃO para os ITENS 2.81.9, 2.81.11, 2.81.14 e 2.81.17

2.81.9. Seleção de Endereço Padrão (Default Address Selection, RFC3484). 2.81.11. SLAAC [RFC4862].

2.81.14. MIBs SNMP para IP (SNMP MIBs for IP, RFC4293) "Encaminhamento" (Forwarding, RFC4292) e DiffServ [RFC3289].

2.81.17. Filtragem UPnP (UPnP filtering).

De acordo com o RIPE 554, os requisitos relativos a IPv6 podem ser divididos em 2 categorias: os “obrigatórios" e os "opcionais”. Segundo o nic.br, através da divulgação do RIPE já mencionado, as RFCs exigidas nos itens 2.81.9, 2.81.11, 2.81.14 e 2.81.17 não são obrigatórias para o uso em switches. A inclusão desses requisitos pode diminuir a competitividade e por

consequência o aumento do preço de aquisição. É nosso entendimento que requisitos não essenciais não devam influenciar nos custos de aquisição.

Pelo que foi exposto anteriormente, sugerimos que estes itens sejam retirados da especificação técnica.

18. SUGESTÃO para TROUBLESHOOTING

As ferramentas de troubleshooting e monitoramento de redes L3 são amplamente divulgadas e conhecidas (e.g. ping, traceroute, etc). Para redes Metro Ethernet ou Switches de Acesso/Borda essa ferramentas podem ser ineficientes ou insuficientes. Para cobrir essa falta, o IEEE e o ITU-T especificaram algumas normas que recomendamos estar presentes em redes projetadas para ter grandes níveis de disponibilidade. Sendo assim, sugerimos os protocolos OAM CFM IEEE 802.1ag, OAM EFM 802.3ah) e ITU-T Y.1731. Basicamente, essas normas disponibilizam alguns protocolos e ferramentas equivalentes existentes em L3 para o ambiente Ethernet, tais como:

Teste de conectividade; Medição de tráfego;

Medição de desempenho da rede, tais como Latência, Jitter e perda de pacotes.

Os principais fabricantes de switches ethernet para redes de acesso implementam esses protocolos padronizados em seus equipamentos, portanto, não devem alterar o custo de aquisição, mas agregarão funcionalidades que ajudarão na administração da rede e no monitoramento dos seus índices de serviço (SLA). Sendo assim, sugerimos a inclusão dos seguintes itens:

Implementar Ethernet Link OAM IEEE 802.3ah; Implementar Ethernet CFM IEEE 802.1ag;

Implementar Ethernet Y.1731 com recursos em MIB para exportação dos contadores de monitoramento de desempenho, tais como packet loss e jitter;

19. SUGESTÃO para QoS

No termo de referência não foi especificado a quantidade mínima de filas de QoS por porta que deverão estar disponíveis para configuração de QoS. Equipamentos de porte compatíveis com esta Especificação disponibilizam 8 filas de QoS por porta. Por isso, a inclusão deste requisito não implicará em aumento de custos, enquanto que garante à

(16)

administração pública que o equipamento fornecido disponibilize este recurso tão importante para implementação com qualidade dos serviços de VOZ, DADOS, VÍDEO, NETWORK CONTROL, MANAGEMENT, BEST EFFORT.

Face ao exposto, sugerimos a inclusão de item conforme abaixo:

Implementar 8 filas de QoS por porta, independentemente da taxa de operação da porta ser 1Gbps ou 10Gbps.

20. SUGESTÕES de Inclusão

A fim de facilitar a operação dos equipamentos, a interoperabilidade, o gerenciamento dos equipamentos, o suporte técnico, a gestão de sobressalentes e o treinamento, sugerimos incluir o seguinte item na especificação técnica:

Todos os equipamentos propostos, em ambos os lotes, deverão ser do mesmo fabricante. Visando garantir que o equipamento atenda a normas técnicas nacionais e internacionais, solicitamos que sejam incluídos os seguintes itens na especificação técnica:

Os equipamentos ofertados deverão ter certificação Anatel, de acordo com os procedimentos regulamentados pela Resolução nº 242/2000. Tais certificados devem ser apresentados junto com a proposta.

Os equipamentos ofertados deverão estar em conformidade com as normas MEF 9 e 14 (CE 1.0).

Visando garantir que o equipamento ofertado não esteja em final de vida, solicitamos que seja incluído o seguinte item na especificação técnica:

O produto ofertado não deve ter “end-of-sales” ou “end-of-life” inferior a 02 (dois) anos na data do pregão.

21. ESCLARECIMENTO

A DATACOM apoia as ações de promoção da tecnologia IPv6, bem como a sua implantação. Prova disso é que nos últimos anos tem capacitado seus produtos para atender esta demanda, com especial foco e prioridade nos protocolos essenciais para operação da rede. Os produtos fornecidos para projetos estratégicos do governo como PNBL e Cidades Digitais, para os quais a DATACOM foi adjudicada como fornecedora, estão capacitados a atender as demandas de migração para IPv6. Funcionalidades secundárias e não essenciais continuam sendo priorizadas no roadmap de desenvolvimento de produto, como é o caso das funcionalidades abaixo:

2.81.2. Filtragem DHCPv6 (DHCPv6 filtering, RFC3315)

2.81.3. Filtragem de Anúncio de Roteador (RA) (Router Advertisement (RA) filtering,RFC4862).

2.81.4. Inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection, RFC4861).

2.81.6. Investigação e filtragem de Detecção de Endereço Repetido (Duplicate Address Detection [DAD, RFC4429] snooping and filtering).

Itens não essenciais limitam a competitividade e, por consequência, encarecem desnecessariamente o processo de aquisição. Além disso, os itens citados acima, serão disponibilizados em breve e não há justificativas para a não aceitação de fornecimento dela após o certame. Pela resolução CGI.br/RES/2013/033, do comitê gestor da internet no Brasil, fica claro que não há consenso sobre cronogramas e metas para a implantação do IPv6 no Brasil. Sendo assim, reforçamos que sejam definidos/permitidos prazos para os fabricantes ajustem seus produtos a determinadas especificações do IPv6 e que ao mesmo tempo atendam aos cronogramas de migração do PRODAM.

(17)

SUGESTÕES REFERENTES AO LOTE 2

2.4. Deve possuir memória RAM no processador central de, no mínimo, 1 (um) GB (GigaByte);

S: Deve possuir memória RAM no processador central de, no mínimo, 512MB(Quinhentos e doze mega bytes de memória RAM );

2.7. Deve possuir, no mínimo, 4 (duas) portas SFP+, ou XFP, populadas com 2 (duas) portas óticas de 1 (um) Gbps monomodo, acompanhadas de cordão óptico de, no mínimo, 2 (dois) metros, com terminação em conectores do tipo LC monomodo e 2 (duas) portas óticas de 10 (dez) Gbps monomodo, acompanhadas de cordão óptico de, no mínimo, 2 (dois) metros, com terminação em conectores do tipo LC monomodo;

S: Deve possuir, no mínimo, 4 (quatro) portas SFP, ou XFP, populadas com 2 (duas) portas óticas de 1 (um) Gbps monomodo, acompanhadas de cordão óptico de, no mínimo, 2 (dois) metros, com terminação em conectores do tipo LC;

2.16. Suportar, no mínimo, 16.000 (dezesseis mil) endereços MAC; S: Suportar, no mínimo, 8.000( oito mil ) endereços MAC;

2.18. Deve permitir no mínimo 5.000 (cinco mil) rotas de Ipv4 em hardware, Remover

Resposta: O ítem não será removido, porém poderá sofrer alterações.

2.43. Deve implementar Bridge MIB, RFC1493; S: Deve implementar Bridge MIB;

Resposta: O ítem não será alterado. A Prodam adota a RFC como padrão.

2.46. Deve implementar RMON MIB, RFC 2819; S: Deve implementar e suportar RMOM MIB;

2.56. Deve implementar no mínimo 256 (duzentos e cinqüenta e seis) grupos multicast L3 IPv4;

S: Deve implementar e suportar grupos multicast L3 IPv4;

2.57. Deve implementar no mínimo 256 (duzentos e cinqüenta e seis) grupos multicast L3 IPv6;

S: Deve implementar e suportar grupos multicast L3 IPv6;

2.58. Deve implementar no mínimo 256 (duzentos e cinqüenta e seis) rotas multicast; S: Deve implementa e suportar rotas multicast;

2.59. Deve implementar no mínimo 256 (duzentos e cinqüenta e seis) gruposmulticast L2; S: Deve implementar e suportar grupos multicast L2;

(18)

2.78. Deve Implementar, no mínimo, 15 (quinze) adjacências OSPFv2 e OSPFv3; S: Deve implementar e suportar os protocolos OSPFv2 e OSPFv3;

2.79. Deve Implementar NSR (Non-stop Routing) para OSPFv3; Remover

2.81.1. MLDv2 snooping (RFC4541) S: Deve suportar MLDv2 snooping;

2.81.4. Inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection, RFC4861)

S: . Deve suportar inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection;

2.81.5. "Filtragem de Detecção de Inacessibilidade de Vizinho" (Neighbor Unreachability Detection [NUD, RFC4861] filtering)

Remover

2.81.6. "Investigação e filtragem de Detecção de Endereço Repetido" (Duplicate Address Detection [DAD, RFC4429] snooping and filtering)

S: Deve suportar "Investigação e filtragem de Detecção de Endereço Repetido" (Duplicate Address Detection [DAD] snooping and filtering)

Resposta: O ítem poderá sofrer alterações.

2.81.7. "Especificação Básica de IPv6" (IPv6 Basic specification, RFC2460) S: "Especificação Básica de IPv6" ( IPv6 Basic specification )

2.81.8. "Arquitetura de Endereçamento IPv6" (IPv6 Addressing Architecture, RFC4291) S: "Arquitetura de Endereçamento IPv6" (IPv6 Addressing Architecture )

2.81.9. "Seleção de Endereço Padrão" (Default Address Selection, RFC3484) S: "Seleção de Endereço Padrão" (Default Address Selection )

2.81.10. ICMPv6 [RFC4443] S: ICMPv6

2.81.11. SLAAC [RFC4862] S: SLAAC

(19)

2.81.12. "Protocolo SNMP" (SNMP protocol, RFC3411) S: Protocolo SNMP( SNMP protocol )

2.81.13. "Funções SNMP" (SNMP capabilities, RFC3412, RFC3413, RFC3414) S: “Funções SNMP" ( SNMP capabilities )

2.81.14. "MIBs SNMP para IP" (SNMP MIBs for IP, RFC4293 S: . "MIBs SNMP para IP" (SNMP MIBs for IP )

"Encaminhamento" (Forwarding, RFC4292) e DiffServ [RFC3289] S: Encaminhamento, forwarding e DiffServ;

2.81.16. "Deprecação de Cabeçalhos de Roteamento 0 em IPv6" (Deprecation of Type 0 Routing Headers in IPv6, RFC5095)

S: "Deprecação de Cabeçalhos de Roteamento 0 em IPv6" ( Deprecation of Type 0 Routing Headers in IPv6 )

2.81.17. "Filtragem UPnP" (UPnP filtering) Remover

Resposta: O ítem não será removido, porém poderá sofrer alterações. Considerar a legenda abaixo para cada item:

o_{A: = Descrição antiga}

o_{S: = Descrição sugerida pela 5F}

o_{Remover = Não conseguimos atender a solicitação com um produto de valor} competitivo para essa requisição ou a Cisco não informa a quantidade ou métrica pois é preciso um levantamento no ambiente proposto/sugerido.

SUGESTÕES REFERENTE AO LOTE 1

1.1.16. Suportar, no mínimo, 32.000 (trinta e dois mil) endereços MAC; S: Suportar, no mínimo, 12.000 (doze mil) endereços MAC;

Remover

1.1.31. Deve implementar a RFC 3580 permitindo que um usuário autenticado por 802.1x seja automaticamente associado a sua respectiva VLAN;

(20)

S: Deve implementar o protocolo 802.1x e permitir que um usuário autenticado seja automaticamente associado a sua respectiva VLAN;

1.1.43. Deve implementar Bridge MIB, RFC1493; S: Deve implementar Bridge MIB;

1.1.45. Deve implementar MIB II, RFC1213; S: Deve implementar MIB II;

1.1.46. Deve implementar RMON MIB, RFC 2819; S: Deve implementar RMON MIB;

1.1.56. Deve implementar no mínimo 512 (quinhentos e doze) grupos multicast L3 IPv4 Remover

1.1.57. Deve implementar no mínimo 512 (quinhentos e doze) grupos multicast L3 IPv6; Remover

1.1.58. Deve implementar no mínimo 512 (quinhentos e doze) rotas multicast; Remover

1.1.59. Deve implementar no mínimo 512 (quinhentos e doze) grupos multicast L2; Remover

1.1.77. Deve Implementar, no mínimo, 10 (dez) áreas OSPFv2 e OSPFv3; S: Deve implementar e suportar os protocolos OSPFv2 e OSPFv3;

1.1.78. Deve Implementar, no mínimo, 30 (trinta) adjacências OSPFv2 e OSPFv3; S: Deve implementar e suportar adjacências com os protocolos OSPFv2 e OSPFv3;

1.1.81.1. MLDv2 snooping (RFC4541) S: Deve suportar MLDv2 snooping;

1.1.81.2 "Filtragem DHCPv6" (DHCPv6 filtering, RFC3315)

S: Deve suportar filtragem de DHCPv6( DHCPv6 filtering ) ou funcionalidade similar;

1.1.81.3 Inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection, RFC4861)

(21)

S: . Deve suportar inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection;

1.1.81.5. "Filtragem de Detecção de Inacessibilidade de Vizinho" (Neighbor Unreachability Detection [NUD, RFC4861] filtering)

Remover

1.1.81.6 "Investigação e filtragem de Detecção de Endereço Repetido" (Duplicate Address Detection [DAD, RFC4429] snooping and filtering)

S: Deve suportar "Investigação e filtragem de Detecção de Endereço Repetido" (Duplicate Address Detection [DAD] snooping and filtering)

1.1.81.7. "Especificação Básica de IPv6" (IPv6 Basic specification, RFC2460) S: "Especificação Básica de IPv6" ( IPv6 Basic specification )

1.1.81.8. "Arquitetura de Endereçamento IPv6" (IPv6 Addressing Architecture, RFC4291) S: "Arquitetura de Endereçamento IPv6" (IPv6 Addressing Architecture )

1.1.81.9. "Seleção de Endereço Padrão" (Default Address Selection, RFC3484) S: "Seleção de Endereço Padrão" (Default Address Selection )

1.1.81.10. ICMPv6 [RFC4443] S: ICMPv6

1.1.81.11. SLAAC [RFC4862] S: SLAAC

1.1.81.12. "Protocolo SNMP" (SNMP protocol, RFC3411) S: Protocolo SNMP( SNMP protocol )

1.1.81.13. "Funções SNMP" (SNMP capabilities, RFC3412, RFC3413, RFC3414) S: “Funções SNMP" ( SNMP capabilities )

1.1.81.14. "MIBs SNMP para IP" (SNMP MIBs for IP, RFC4293 S: . "MIBs SNMP para IP" (SNMP MIBs for IP )

"Encaminhamento" (Forwarding, RFC4292) e DiffServ [RFC3289] S: Encaminhamento, forwarding e DiffServ;

(22)

1.1.81.16. "Deprecação de Cabeçalhos de Roteamento 0 em IPv6" (Deprecation of Type 0 Routing Headers in IPv6, RFC5095)

S: "Deprecação de Cabeçalhos de Roteamento 0 em IPv6" ( Deprecation of Type 0 Routing Headers in IPv6 )

1.1.81.17. "Filtragem UPnP" (UPnP filtering) Remover

São Paulo, 29 de abril de 2014.

MARCIO DE ANDRADE BELLISOMI JOSÉ MAURO GOMES

Diretor-Presidente Diretor de Administração e Finanças

MARCELO ANDRADE PIMENTA