Resumen

  • Los módulos ietf-pcep e ietf-pcep-stats proporcionan una forma común de administrar y observar entidades, pares, sesiones, eventos, acciones y estadísticas PCEP.
  • La semántica NMDA permite señalar intención, estado operacional y origen, pero no autentica por sí sola al par ni fecha el hecho de protocolo observado.
  • Para decidir, hay que unir la lectura de gestión con la autorización, la sesión PCEP, la decisión del controlador, la aceptación del PCC, el estado del equipo y el tráfico.

Una organización puede perder el rastro causal precisamente cuando gana un cuadro de mando mejor. Antes había registros inconexos; después de la normalización, una sola pantalla parece ofrecer una verdad total. RFC 9826 resuelve el primer problema. No promete resolver el segundo.

El texto de RFC 9826 define un modelo YANG 1.1 para administrar hablantes PCEP. ietf-pcep cubre entidad local, pares, sesiones, notificaciones y RPC. ietf-pcep-stats suma tiempos de respuesta, contadores y telemetría. La ficha editorial, el expediente del IETF, la búsqueda de erratas y el registro YANG de IANA fijan qué documento y módulos son oficiales. No certifican una implementación concreta.

Tres preguntas antes de leer una hoja

La primera pregunta es qué clase de dato vemos. La entidad incluye admin-status, deseo operativo, y oper-status, resultado actual del intento de alcanzarlo. Una configuración habilitada no equivale a un proceso activo. El árbol conserva ambas piezas para que el consumidor no cierre prematuramente la diferencia.

La segunda pregunta es de dónde procede el valor. NMDA coloca en <operational> configuración aplicada desde <intended>, configuración dinámica, aprendida, del sistema o predeterminada, además del estado propio del sistema. La anotación origin mejora la procedencia. No es una firma del par PCEP ni una prueba del flujo de paquetes. YANG 1.1 define el lenguaje; no inspecciona el dispositivo.

La tercera pregunta es quién puede verlo o cambiarlo. NACM restringe operaciones, contenido y notificaciones. Una notificación puede descartarse para una suscripción sin permiso. Por tanto, el silencio del canal no demuestra que no hubo caída o sobrecarga. La autenticación mutua del protocolo de gestión y la autorización de una acción tampoco son sinónimos.

Un par por dirección, una sesión por instante

RFC 9826 usa la dirección IP para indexar un par. Eso estabiliza el árbol local, pero no demuestra la identidad duradera del operador remoto. El PCEP base sitúa el establecimiento después de que ambos extremos reciben Keepalive. Durante una colisión pueden existir dos sesiones candidatas, una iniciada localmente y otra por el par; la lista de RFC 9826 las distingue por iniciador hasta que una queda descartada.

Una lectura de session-up debe conservar state-last-change, la hora de lectura, la conexión de transporte y la prueba de identidad. Los ID de sesión ayudan a diagnosticar, pero no son identidades globales. Los temporizadores negociados pertenecen a esa sesión y a ese momento.

Los contadores tienen una fragilidad distinta. discontinuity-time marca el comienzo de su época. Las estadísticas de la sesión actual se pierden al caer la sesión. Una acción puede borrar las estadísticas de un contenedor y el RPC global puede borrar todas. Sin el instante de discontinuidad y los tiempos de reset, una serie puede confundir reinicio con mejora. Contar PCReq, PCRep, PCUpd o errores demuestra clasificación local, no corrección semántica ni ejecución posterior.

trigger-resync permite pedir al PCE una resincronización con un PCC. La respuesta del RPC confirma la tramitación de una orden, no el acuerdo final. RFC 9826 identifica como sensibles tanto el resync no autorizado como el reset global de estadísticas. Hay que conservar principal autenticado, decisión NACM, orden, respuesta, intercambio PCEP y lectura reconciliada.

Una LSP-DB no observa la placa de reenvío

En un PCE con estado, la LSP-DB operacional se indexa por PLSP-ID, dirección PCC y LSP-ID. RFC 8231 define sincronización, delegación, PCRpt y PCUpd. RFC 9826 modela ese estado; no lo convierte en comprobación del forwarding.

Este límite evita absorber otros mecanismos. RFC 9504 conserva la delegación GMPLS; RFC 9830, el candidate path SR Policy transportado por BGP; RFC 9863, el color PCEP; y RFC 9916, el orden TLS de PCEPS. El modelo puede exponer capacidades relacionadas sin probar que la semántica de esos estándares se aceptó o que produjo servicio.

La correspondencia con el MIB PCEP es deliberada. Sirve para migrar observabilidad, no para duplicar testigos: si MIB y YANG nacen del mismo contador interno, coincidir no constituye corroboración independiente.

En Running-Code Primacy, el artefacto común queda subordinado a la realidad ejecutada. Minimum Initial Specification mantiene las decisiones futuras en manos de quienes implementan. Reality, Not Advocacy impide presentar deseo como observación. Aplicadas aquí, son reglas editoriales, no una lectura de la intención del IETF.

La prueba completa empieza con módulo y features, datastore, origin, instante y época. Continúa con identidad y permiso de gestión, transporte y par PCEP, sesión negociada, decisión del controlador, respuesta del PCC, aplicación del dispositivo, forwarding y resultado del servicio. Un árbol común hace visible la primera mitad. No autoriza a omitir la segunda.