Resumo

  • O RFC 9903 é um documento IETF Standards Track, publicado em dezembro de 2025. Ele define o módulo YANG ietf-ospf-sr-mpls para administrar Segment Routing sobre MPLS em OSPFv2 e OSPFv3 e aumenta o modelo OSPF do RFC 9129.
  • O módulo depende do RFC 9020 para recursos de SR independentes de protocolo e usa seus agrupamentos para bindings de Mapping Server no nível da instância, SRGB por protocolo e Adj-SIDs de interface. Uma superfície comum não iguala os formatos de fio das duas versões.

A leitura operacional deve separar instância, área e interface. No nível da instância ficam relações como bindings de Mapping Server e SRGB por protocolo. No nível da área, a configuração habilita SR-MPLS em todas as interfaces daquela área e anuncia informação de SR-MPLS em LSAs. Portanto, a habilitação de área não é local a uma interface. No nível da interface, o modelo representa Adj-SIDs para vizinhos específicos em interfaces broadcast ou NBMA de múltiplo acesso e representa TI-LFA sobre MPLS.

O RFC 9129 é o modelo OSPF-base que o RFC 9903 aumenta; o RFC 9020 fornece o modelo-base de recursos de SR. Isso não significa que o módulo faça encaminhamento, calcule caminhos ou atribua rótulos. TI-LFA e SR-based Remote LFA são capacidades opcionais, e remote-lfa-sr só se aplica quando Remote LFA está habilitado. O uso de Mapping Server também não é obrigatório.

O estado operacional exige leitura sensível à versão. No OSPFv2, Prefix Range e Prefix-SID são mapeados para Extended Prefix Opaque LSAs; algorithm, SID/Label Range, SR Local Block e SRMS Preference são mapeados para Router Information Opaque LSAs. No OSPFv3, Prefix Range e Prefix-SID aparecem nas suas extended prefix LSAs/TLVs; Adj-SID e LAN Adj-SID aparecem em Router-Link TLVs; algorithm, range, local block e SRMS preference aparecem em Router Information LSAs. Assim, Opaque LSA, Extended LSA e cada família de TLV continuam sendo evidências diferentes.

A segurança faz parte do limite de controle. O acesso por NETCONF ou RESTCONF deve usar transporte seguro e autenticação mútua. O NACM pode restringir usuários a operações e conteúdos autorizados. Mudanças não autorizadas em habilitação de SR, bindings, SRGB do protocolo, Adj-SIDs ou TI-LFA podem interromper, redirecionar ou negar tráfego. As extensões legíveis da LSDB de OSPFv2 e OSPFv3 também podem revelar prefixos, algoritmos, ranges, blocos locais, dados de SRMS e topologia úteis a um atacante.

Verificações concretas para o operador

  1. Identifique a versão OSPF em cada instância e associe a ela o leitor de estado correto; não trate uma família de LSA como substituta da outra.
  2. Antes de escrever, salve bindings de instância, SRGB por protocolo, habilitação de área, Adj-SIDs de vizinhos e as condições de TI-LFA/Remote LFA.
  3. Selecione uma área controlada e confirme que sua habilitação alcançará todas as interfaces da área, incluindo os vizinhos que serão afetados.
  4. Depois da mudança, leia separadamente as Extended Prefix e Router Information Opaque LSAs do OSPFv2, ou as Extended Prefix, Router-Link TLVs e Router Information LSAs do OSPFv3.
  5. Teste NETCONF/RESTCONF com transporte seguro, autenticação mútua e NACM; confirme que a autorização de escrita não concede leitura ampla da LSDB.
  6. Compare estado anterior, estado esperado e reversão para cada versão. Se bindings, SRGB, Adj-SIDs, habilitação de área ou TI-LFA não coincidirem, interrompa a expansão e faça rollback da versão correspondente.

Fontes