Resumo

  • RFC 5195 permite transportar capacidade de comutação e largura de banda máxima de interfaces L1VPN para seleção de saída. O atributo é uma declaração de descoberta; não mede necessariamente a folga atual e não prova que recursos foram reservados.
  • O mesmo limite vale para a associação CPI/PPI: recebê-la, importá-la e instalá-la na PIT prepara a sinalização. Autoridade de origem, admissão, reserva, conexão cruzada e tráfego exigem recibos próprios.

O salto entre três substantivos

Máximo, disponível e reservado parecem variações do mesmo número. Operacionalmente, são objetos diferentes.

O máximo é um limite anunciado por uma interface remota. O disponível depende do instante, das demais alocações e do modelo de contabilização. O reservado é o resultado de uma decisão de admissão para uma solicitação identificada. Só o último cria um compromisso de recurso.

RFC 5195 permite que o mecanismo de descoberta carregue informações de engenharia de tráfego para seleção de saída, citando capacidade de comutação e largura de banda máxima de LSP. O propósito é ajudar a escolher onde tentar. Nada nessa descrição transforma o anúncio em telemetria instantânea ou recibo de reserva.

O sistema preserva a verdade quando mantém as palavras originais. Deve registrar fonte e horário do atributo, depois a medição operacional, a decisão de admissão e o identificador da reserva. Reutilizar um campo e apenas trocar seu rótulo cria certeza sem novo observador.

Descoberta entrega o endereço da próxima ação

O núcleo de RFC 5195 é a distribuição de associações entre Customer Port Identifier e Provider Port Identifier. O CPI é único dentro do L1VPN; o PPI é único na rede do provedor. Cada PE mantém uma Port Information Table para os VPNs que possuem portas locais.

Uma parte da PIT vem da configuração local ou dos CEs conectados. Outra chega de PEs remotos por BGP. As associações permitem resolver o destino durante a fase de sinalização e sustentam o provisionamento em uma única extremidade.

A formulação é importante: a informação é necessária para completar a sinalização. Ela não completa a sinalização. Uma linha pode ser descoberta antes de existir uma solicitação, continuar visível após uma rejeição de capacidade ou sobreviver a uma falha de conexão cruzada.

Por isso, a operação precisa de estados distintos: anúncio recebido, política aceita, PIT atualizada, sinalização iniciada, admissão aprovada, recurso reservado, equipamento conectado, continuidade verificada e tráfego confirmado.

Route Target delimita distribuição, não autorização

Comunidades Route Target controlam quais informações entram em cada PIT. Targets de exportação marcam o conteúdo local; targets de importação selecionam o que o PE aceita. É uma técnica de escala e isolamento.

A seleção correta prova que a regra local funcionou. Não prova que o cliente autorizou aquele site, que a porta continua conectada ou que o originador tinha mandato para anunciar o par. Uma política equivocada pode ser executada sem erro de protocolo.

RFC 5195 considera crítico que um PE só seja descoberto em um VPN se estiver realmente conectado e devidamente autorizado. Para um par direto, recomenda autenticação BGP. A autenticação protege a identidade do vizinho, mas não assina a legitimidade comercial de cada informação transportada.

Quando há locutores intermediários, a confiança passa por uma cadeia. O PE local precisa acreditar que seu vizinho aceitou dados apenas de outros vizinhos confiáveis. O RFC afirma que BGP não permite determinar se uma informação específica nasceu em um locutor autorizado a anunciá-la. Por isso restringe o uso a ambientes com relações de confiança adequadas, dando uma rede de provedor único como exemplo.

O valor pode estar fresco e a associação estar velha

Combinar TE e descoberta em uma única linha produz outra armadilha. O atributo de capacidade pode ter sido atualizado recentemente, enquanto a associação CPI/PPI foi retida indevidamente por uma projeção. Ou o par pode estar correto e o máximo ter envelhecido.

Um timestamp único para a linha esconde essas diferenças. Cada afirmação precisa de origem, versão e validade próprias. Só então uma seleção de saída consegue explicar qual associação usou, qual dado de engenharia avaliou e qual reserva resultou.

Join e Prune não terminam no commit

Sem Route Target compatível, um PE que não seja refletor deve descartar a informação L1VPN recebida. Se um novo target for adicionado em uma operação de VPN Join, o PE precisa readquirir o que descartou; RFC 5195 exige Route Refresh.

Logo, política instalada, refresh concluído, rotas readquiridas e PIT reconciliada são fatos separados. No VPN Prune, remover o último target relevante permite descartar as rotas. A sessão BGP pode permanecer de pé, mas caches e consumidores ainda precisam confirmar a remoção.

A continuidade da sessão é boa engenharia. Não é um atestado de que o universo local ficou completo após Join ou limpo após Prune.

Partições tornam o escopo parte do dado

Refletores podem ser particionados entre VPNs. Também podem existir vários sistemas BGP independentes transportando informação de VPN. Assim, nenhum componente precisa guardar tudo.

Uma visão de capacidade ou membros precisa declarar a partição observada, os produtores esperados, a política, o estado de refresh e o horário da reconciliação. Duas visões podem ser consistentes em escopos diferentes. Somar seus números sem entender o escopo produz uma disponibilidade fictícia.

Recibo mínimo para não vender o anúncio duas vezes

Para a descoberta, registrar VPN, CPI, PPI, procedência local ou remota, vizinho imediato, origem observada, Route Targets, decisão de importação e base de autoridade. Para TE, registrar separadamente atributo, fonte, horário e validade.

Para a execução, registrar solicitação de sinalização, avaliação de admissão, reserva, estado da conexão cruzada, continuidade e teste de tráfego. Join, Prune e retirada precisam chegar aos consumidores. Esse recibo é uma inferência operacional, não uma extensão do formato de RFC 5195.

A disciplina de camadas de realidade de Heng Lu impede que um símbolo ganhe poder por repetição. Máximo continua máximo; descoberto continua descoberto. O código em execução e o caminho óptico decidem o que existe. O painel só pode resumir essas provas se permitir decompô-las.

Fontes

  1. RFC 5195 em HTML
  2. RFC 5195 em texto
  3. Página informativa da RFC 5195
  4. IETF Datatracker: RFC 5195
  5. Histórico da RFC 5195
  6. Referências da RFC 5195
  7. Errata da RFC 5195
  8. RFC 4847
  9. RFC 5251
  10. RFC 4760
  11. RFC 4360
  12. RFC 4684
  13. RFC 2918
  14. RFC 5291
  15. RFC 2385
  16. RFC 4271
  17. RFC 5925
  18. Heng Lu — camadas de realidade e poder simbólico
  19. Heng Lu — especificação inicial mínima
  20. Heng Lu — primazia do código em execução