ATA DA CONSULTA TÉCNICA N.

Transcrição

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: 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 Deve permitir no mínimo (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 rotas IPv4 são suficientes Deve implementar DHCP Tracker Funcionalidade não encontrada em todos fabricantes 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 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 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 IPv 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 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 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 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 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: 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. 3. SUGESTÃO para o ITEM Deve possuir fonte de energia interna redundante; O item 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. Com base no que foi exposto, sugerimos que o texto seja alterado para: 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 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 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: Deve implementar funcionalidade de espelhamento de tráfego TX e RX; Resposta: O conteúdo do Ítem será alterado. 5. ESCLARECIMENTO sobre os ITENS , , e Os itens , , e 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 Deve permitir no mínimo (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 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 é rotas IPv4 e 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: Deve permitir no mínimo (doze mil) rotas de IPv4 e (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 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. 8. ESCLARECIMENTO sobre o ITEM Deve implementar IEEE 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 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: Deve implementar IEEE 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. 9. SUGESTÃO para o ITEM 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: Deve implementar os seguintes protocolos de roteamento em todas as suas interfaces: OSPF (IPv4), BGP4 (IPv4/IPv6) e OSPFv3 (IPv6).

5 10. SUGESTÃO para o ITEM 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: Deve ter suporte a Radius/Tacacs Authentication, Authorization e Accounting A Prodam utiliza ambos os protocolos de AAA 11. SUGESTÃO para o ITEM 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: 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 Deve implementar Multicast IPv4. Sugerimos a alteração da especificação para: Deve implementar Multicast IPv4 e IPv SUGESTÃO para o ITEM Deve suportar Inbound Rate Limiting; O item 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 seja alterado para: 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); 14. SUGESTÃO para o ITEM 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 , 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: Deve ser possível informar, por porta e VLAN do switch, a quantidade de endereços MACs que podem ser aprendidos; 15. SUGESTÃO para o ITEM 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 seja alterado para: 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 Deve suportar Broadcast Suppression, permitindo configurar valores individuais de supressão por porta; O item 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. 17. ESCLARECIMENTO sobre o ITEM 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: Deve Implementar Graceful Restart (Helper Mode) para OSPF/BGP (para IPv4 e IPv6) segundo RFCs 3623 e 4724; 18. SOLICITAÇÃO para os ITENS , , e Seleção de Endereço Padrão (Default Address Selection, RFC3484) SLAAC [RFC4862] MIBs SNMP para IP (SNMP MIBs for IP, RFC4293) "Encaminhamento" (Forwarding, RFC4292) e DiffServ [RFC3289] 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 , , e 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 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; 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 Framework for Layer 2 Virtual Private Networks (L2VPNs). Implementar RFC Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks. Implementar VPLS com sinalização LDP - RFC 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: Filtragem DHCPv6 (DHCPv6 filtering, RFC3315) Filtragem de Anúncio de Roteador (RA) (Router Advertisement (RA) filtering,rfc4862) Inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection, RFC4861) 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 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 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. Com base no que foi exposto, sugerimos que o texto seja alterado para: 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. 3. SUGESTÃO para o ITEM 2.11

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. Com base no que foi exposto, sugerimos que o texto seja alterado para: 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 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: 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 Deve permitir no mínimo (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: Deve permitir no mínimo (cinco mil) rotas de IPv4 e (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 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. 8. ESCLARECIMENTO sobre o ITEM Deve implementar IEEE 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: Deve implementar IEEE 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. 9. SUGESTÃO para o ITEM 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: 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 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: Deve ter suporte a Radius/Tacacs Authentication, Authorization e Accounting 10. SUGESTÃO para o ITEM 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: Deve Possuir 1 (uma) porta RS-232C (conector DB-9 ou RJ-45) para fins de gerenciamento via console). 11. SUGESTÃO para o ITEM Deve implementar Multicast IPv4. Sugerimos a alteração da especificação para: Deve implementar Multicast IPv4 e IPv SUGESTÃO para o ITEM 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: 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); 13. SUGESTÃO para o ITEM 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: Deve ser possível informar, por porta e VLAN do switch, a quantidade de endereços MACs que podem ser aprendidos; 14. SUGESTÃO para o ITEM 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: 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 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: 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. 16. ESCLARECIMENTO sobre o ITEM 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: Deve Implementar Graceful Restart (Helper Mode) para OSPF/BGP (para IPv4 e IPv6) segundo RFCs 3623 e 4724; 17. SOLICITAÇÃO para os ITENS , , e Seleção de Endereço Padrão (Default Address Selection, RFC3484) SLAAC [RFC4862] MIBs SNMP para IP (SNMP MIBs for IP, RFC4293) "Encaminhamento" (Forwarding, RFC4292) e DiffServ [RFC3289] 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 , , e 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 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: Filtragem DHCPv6 (DHCPv6 filtering, RFC3315) Filtragem de Anúncio de Roteador (RA) (Router Advertisement (RA) filtering,rfc4862) Inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection, RFC4861) 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 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; Suportar, no mínimo, (dezesseis mil) endereços MAC; S: Suportar, no mínimo, 8.000( oito mil ) endereços MAC; Deve permitir no mínimo (cinco mil) rotas de Ipv4 em hardware, Remover Resposta: O ítem não será removido, porém poderá sofrer alterações Deve implementar Bridge MIB, RFC1493; S: Deve implementar Bridge MIB; A Prodam adota a RFC como padrão Deve implementar RMON MIB, RFC 2819; S: Deve implementar e suportar RMOM MIB; A Prodam adota a RFC como padrão 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; 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; Deve implementar no mínimo 256 (duzentos e cinqüenta e seis) rotas multicast; S: Deve implementa e suportar rotas multicast; 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; Deve Implementar NSR (Non-stop Routing) para OSPFv3; Remover Resposta: O ítem não será removido, porém poderá sofrer alterações MLDv2 snooping (RFC4541) S: Deve suportar MLDv2 snooping; A Prodam adota a RFC como padrão 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; A Prodam adota a RFC como padrão "Filtragem de Detecção de Inacessibilidade de Vizinho" (Neighbor Unreachability Detection [NUD, RFC4861] filtering) Remover Resposta: O ítem não será removido, porém poderá sofrer alterações "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) "Especificação Básica de IPv6" (IPv6 Basic specification, RFC2460) S: "Especificação Básica de IPv6" ( IPv6 Basic specification ) "Arquitetura de Endereçamento IPv6" (IPv6 Addressing Architecture, RFC4291) S: "Arquitetura de Endereçamento IPv6" (IPv6 Addressing Architecture ) "Seleção de Endereço Padrão" (Default Address Selection, RFC3484) S: "Seleção de Endereço Padrão" (Default Address Selection ) ICMPv6 [RFC4443] S: ICMPv SLAAC [RFC4862] S: SLAAC

19 "Protocolo SNMP" (SNMP protocol, RFC3411) S: Protocolo SNMP( SNMP protocol ) "Funções SNMP" (SNMP capabilities, RFC3412, RFC3413, RFC3414) S: Funções SNMP" ( SNMP capabilities ) "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; "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 ) "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 Suportar, no mínimo, (trinta e dois mil) endereços MAC; S: Suportar, no mínimo, (doze mil) endereços MAC; Deve permitir no mínimo (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; Remover Resposta: O ítem não será removido, porém poderá sofrer alterações 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; A Prodam adota a RFC como padrão Deve implementar Bridge MIB, RFC1493; S: Deve implementar Bridge MIB; A Prodam adota a RFC como padrão Deve implementar MIB II, RFC1213; S: Deve implementar MIB II; A Prodam adota a RFC como padrão Deve implementar RMON MIB, RFC 2819; S: Deve implementar RMON MIB; A Prodam adota a RFC como padrão Deve implementar no mínimo 512 (quinhentos e doze) grupos multicast L3 IPv4 Remover Resposta: O ítem não será removido, porém poderá sofrer alterações Deve implementar no mínimo 512 (quinhentos e doze) grupos multicast L3 IPv6; Remover Resposta: O ítem não será removido, porém poderá sofrer alterações Deve implementar no mínimo 512 (quinhentos e doze) rotas multicast; Remover Resposta: O ítem não será removido, porém poderá sofrer alterações Deve implementar no mínimo 512 (quinhentos e doze) grupos multicast L2; Remover Resposta: O ítem não será removido, porém poderá sofrer alterações Deve Implementar, no mínimo, 10 (dez) áreas OSPFv2 e OSPFv3; S: Deve implementar e suportar os protocolos OSPFv2 e OSPFv3; 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; MLDv2 snooping (RFC4541) S: Deve suportar MLDv2 snooping; A Prodam adota a RFC como padrão "Filtragem DHCPv6" (DHCPv6 filtering, RFC3315) S: Deve suportar filtragem de DHCPv6( DHCPv6 filtering ) ou funcionalidade similar; A Prodam adota a RFC como padrão Inspeção dinâmica de "solicitação/anúncio de Vizinho IPv6" (Dynamic "IPv6 Neighbor solicitation/advertisement" inspection, RFC4861)