Resumo

  • A revisão 07 do rascunho do grupo LSR do IETF, datada de 29 de setembro, exige que o identificador remoto divulgado para cada membro de um agregado L2 seja exatamente o identificador local não nulo de 32 bits que o vizinho anuncia para o mesmo membro. A revisão 06 recomendava usar o Port ID obtido via LLDP.
  • O novo texto distingue descobrir a porta física de conhecer o identificador numérico correto. LLDP e LACP ainda podem apoiar a descoberta, mas seus valores não substituem a checagem. A autenticação do anúncio IGP tampouco valida a informação L2 que originou a associação.

Um enlace agregado pode reunir vários membros físicos e apresentar apenas um vínculo lógico ao roteamento. Para calcular tráfego por membro ou identificar com precisão uma falha, porém, um controlador precisa unir as duas pontas de cada ligação física. O documento Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members propõe divulgar os identificadores remotos por OSPF ou IS-IS e levá-los até quem consome BGP-LS. A publicação da versão 07 não comprova adoção nem desempenho em campo; ela muda a base exigida para afirmar qual membro existe do outro lado.

Na versão 06, de 22 de agosto, a orientação era adquirir o Port ID do vizinho com LLDP e utilizá-lo como identificador remoto no anúncio. Números de porta do LACP apareciam como outra possibilidade. A versão 07 deixa de tratar esses valores como equivalentes automáticos. Cada roteador atribui um número local não nulo de 32 bits a seus membros. Ao divulgar o ID remoto de um deles, deve empregar exatamente o número que o roteador vizinho divulga como ID local do membro correspondente. A reciprocidade permite ao controlador confrontar as duas descrições do mesmo cabo.

O detalhe técnico explica a revisão. O Port ID do LLDP depende de subtipo e pode nem ser um valor numérico de 32 bits. Os números de porta Actor e Partner do LACP têm 16 bits e são atribuídos de modo independente em cada ponta. Identificar uma porta com esses protocolos não resolve automaticamente como ela se relaciona ao identificador que aparece no atributo de membro do vizinho. A obtenção desse número exato fica fora do escopo do rascunho; uma implementação pode recorrer a configuração ou a descoberta própria, mas terá de fazer e verificar o mapeamento. LLDP e LACP não estão proibidos.

Considere um cenário hipotético em que o membro A de um roteador seja associado ao X errado no vizinho. A descoberta da porta era real, mas a tradução para o ID local anunciado pelo outro lado estava incorreta. A autenticação IGP prova a origem da mensagem, não a precisão da observação de camada 2 anterior a ela. A seção de segurança ampliada da revisão 07 explicita essa fronteira de confiança: uma associação falsa pode afetar engenharia de tráfego ou correlação de falhas. O documento não relata uma ocorrência concreta nem acusa fornecedor específico.

Também não se deve ler ausência de ID como ausência de membro. O valor pode simplesmente não ter sido aprendido ou divulgado, inclusive quando só um lado implementa a extensão. Em IS-IS, zero pode marcar a posição de um membro com ID remoto desconhecido; ao exportar para BGP-LS, esse zero não vira ID válido. O propagador de BGP-LS não é responsável por julgar a semântica da associação, tarefa que cabe ao consumidor. Para uma implantação parcial, preservar a diferença entre «desconhecido» e «inexistente» impede conclusões artificiais sobre a topologia.

O Datatracker apresenta a versão 07 como Internet-Draft ativo, em IESG Last Call até 13 de outubro, com status Proposed Standard pretendido. Ainda não é um RFC. A regra de habilitar o anúncio somente por configuração em enlaces escolhidos já estava na versão anterior; a revisão se destaca pelo que passa a ser necessário demonstrar depois dessa habilitação.

Fontes