Resumen
ietf-layer1-typesaporta identidades, tipos y agrupaciones reutilizables para expresar señales, ODUs, ancho de banda y etiquetas OTN; por sí solo no expone nodos de configuración, estado ni RPC.- Un rango visible es evidencia sobre una representación. No demuestra que siga libre, que ambos extremos lo admitan, que una operación lo haya reservado ni que el plano óptico transporte el servicio.
La ranura 17 aparece en la pantalla
El controlador lee una topología y encuentra una gama de Tributary Slots. La ranura 17 cabe en la restricción, la granularidad parece correcta y el tipo de ODU coincide con la solicitud. Es tentador escribir en el informe que la capacidad “está disponible”.
La pantalla ha demostrado algo más modesto. Un servidor produjo datos que, bajo el esquema instanciado y el snapshot observado, representaban la ranura dentro de una gama. No ha bloqueado la ranura. No ha consultado necesariamente el estado más reciente del otro extremo. No ha coordinado una etiqueta igual a ambos lados del enlace. No ha cerrado el cross-connect.
La revisión 20 de Common YANG Data Types for Layer 1 Networks se publicó el 14 de septiembre de 2026 y caduca el 18 de marzo de 2027. Datatracker la presenta como documento activo del grupo CCAMP, destinado a Proposed Standard y en la cola del RFC Editor. Es un trabajo avanzado, pero no es un RFC ni una prueba de que una red o un producto concreto lo haya desplegado.
El valor editorial de este caso está en separar el contador de la autoridad. El modelo sabe cómo contar y describir. La reserva pertenece a otro sistema y a otro momento.
La biblioteca común evita nueve dialectos
Las redes ópticas reúnen conceptos que se deforman con facilidad al pasar de un estándar a una API privada: unidades ópticas, clientes, granularidades, puertos tributarios, conjuntos de ranuras, prioridades, límites y casos flexibles. Si cada modelo inventa su propia estructura, una integración puede parecer correcta mientras intercambia significados diferentes.
ietf-layer1-types ofrece una base común. Las granularidades de 1,25G, 2,5G y 5G tienen identidades. odu-type da una raíz extensible a las clases de ODU. client-signal ordena familias como Ethernet, STM, OC y Fibre Channel. Las agrupaciones OTN enriquecen los tipos generales de ingeniería de tráfico con información que el nivel óptico necesita.
El beneficio es concreto: menos conversores privados, validación más reproducible y mayor posibilidad de reutilizar una herramienta entre topologías, túneles y servicios. La normalización no es papel sin efecto; es una reducción del coste de coordinación.
Precisamente por eso conviene no prometer más. Una identidad común prueba que dos modelos pueden referirse al mismo concepto. No prueba que dos equipos lo implementen de forma interoperable. El borrador recuerda que ciertos tipos pueden residir en módulos específicos de proveedor porque la especificación relacionada no garantiza interoperabilidad en el plano de datos.
Una lengua común puede permitir una conversación. No garantiza que ambos interlocutores puedan ejecutar la orden descrita.
El módulo no contiene el botón
Las consideraciones de seguridad de la revisión 20 fijan una frontera explícita. El módulo define identidades, tipos y agrupaciones reutilizables. Solo, no expone nodos escribibles, nodos de estado de solo lectura ni RPC.
Por eso un árbol de agrupación que muestra hojas rw no equivale a una API activa. El árbol enseña la forma que adoptarían las hojas cuando otro módulo las instancie. Faltan el módulo consumidor, la ruta del datastore, las features, las deviations y la implementación del dispositivo.
La diferencia también explica dónde aparece la sensibilidad. La biblioteca sola no ofrece una superficie de datos. Un modelo que instancie ancho de banda, gama de etiquetas o extremos de rango sí puede revelar topología OTN sensible. Ese modelo debe declarar sus riesgos y controles.
Un inventario serio pregunta qué módulo y revisión anuncia cada equipo, qué features implementa, qué desviaciones aplica y en qué ruta aparecen los nodos. “Soporta YANG” no responde a ninguna de esas preguntas. “Importa ietf-layer1-types” tampoco.
Ochenta ranuras no son ochenta reservas
La revisión 20 describe una situación en la que un enlace de 100G puede admitir un ODU4, diez ODU2 u ochenta ODU0. Son expresiones alternativas de un recurso subyacente. Sumarlas sería contar la misma capacidad varias veces.
El groupement otn-link-bandwidth estructura esa información por tipo. Un planificador todavía debe resolver ocupación, fragmentación, prioridad, capacidades en los extremos y continuidad a lo largo del camino. La capacidad potencial no es el inventario comprometido.
Las etiquetas OTN añaden otra obligación. Normalmente combinan un Tributary Port Number y un conjunto de Tributary Slots. La misma etiqueta debe asignarse al mismo LSP en ambos extremos del enlace. Una gama indica valores que pueden emplearse para el establecimiento según las reglas pertinentes.
Para convertir la ranura 17 en evidencia de reserva se necesita un identificador de transacción, exclusión frente a competidores, aceptación en los dos extremos, commit y lectura posterior. Si el controlador usa datos con treinta segundos de antigüedad, debe conservar esa edad. Si dos peticiones compiten, debe conservar tanto el resultado ganador como el conflicto de la perdedora.
Un informe que solo guarda el rango inicial no puede distinguir una carrera, un snapshot obsoleto, una política que denegó la solicitud o un fallo de aplicación. La semántica precisa del modelo se pierde en un registro operativo impreciso.
ODUflex demuestra por qué un número no basta
ODUflex no tiene una única fórmula de velocidad. La revisión 20 modela seis formas y utiliza un choice para conservar los parámetros que necesita cada una: velocidad nominal genérica, cliente CBR, n y k de GFP, cliente FlexE, recuento FlexE-aware o payload de paquetes.
El caso genérico permite que un dominio de tránsito represente una velocidad sin conocer el tipo exacto cuando el establecimiento no depende de él. Eso favorece compatibilidad futura. El texto recomienda usarlo solo cuando haga falta y preferir la forma específica siempre que sea posible para simplificar la interoperabilidad.
La recomendación muestra un intercambio, no una jerarquía moral. Más abstracción puede ampliar el tránsito; menos detalle puede impedir que otro dominio calcule o valide la adaptación. El recibo debe decir qué caso se usó y qué información quedó fuera.
Además, el número de ODUs disponibles no permite deducir por sí solo el ancho de banda ODUflex disponible. El número de slots y el tipo de ODTU cambian el cálculo. La matriz de conectividad y los enlaces locales pueden imponer límites adicionales.
Por eso el panel “ODUflex disponible: 1” no es una verdad atómica. Debe abrirse hasta revelar la fórmula, el ODTU, la granularidad, los extremos y el camino bajo el cual esa cifra es válida.
Redimensionable no significa redimensionado
El modelo separa ODUflex de ODUflex-resizable. La segunda identidad sirve para expresar compatibilidad con procedimientos de cambio de velocidad sin interrupción y límites asociados.
Que la identidad compile prueba la coherencia del vocabulario. Que un equipo la anuncie aporta evidencia de capacidad declarada. Que una configuración la seleccione aporta evidencia de intención. Ninguno de esos hechos mide una transición real.
Para afirmar que el cambio fue hitless hacen falta recursos antes y después, sincronización entre extremos, estado operacional y observaciones durante la ventana: alarmas, errores, continuidad y tráfico del cliente. Un nombre no puede suministrar una serie temporal.
La distinción permite diseñar mejores pruebas. El modelo dice qué capacidad esperar; el ensayo determina si la implementación la cumple.
Una petición válida puede no tener autoridad
NETCONF y RESTCONF transportan operaciones sobre datos modelados con YANG. La capa segura y la autenticación mutua establecen quién se conecta bajo las anclas configuradas. NACM decide si esa identidad puede acceder a la operación y al contenido solicitados.
Son comprobantes separados. Una carga puede ser válida según el esquema y ser rechazada por autorización. Puede estar autorizada y fallar por conflicto de recursos. Puede obtener respuesta positiva en un datastore candidato y no haber sido confirmada. Puede llegar a la configuración prevista y tardar en aparecer en el estado operacional.
NMDA conserva la diferencia entre intención y realidad operacional. Esa diferencia no es un fallo del estándar; es el lugar donde se hacen visibles la aplicación asíncrona, los valores derivados y las restricciones del sistema.
Después queda el plano físico. Un cross-connect declarado activo puede coincidir con pérdida de señal, errores o una adaptación de cliente incompatible. La telemetría del servicio no debe ser sustituida por la respuesta del canal de gestión.
Un expediente que pueda sobrevivir a la avería
La primera capa del expediente fija el borrador y la revisión del módulo, los hashes, las dependencias y el validador. La segunda compara los conjuntos de módulos, features y deviations de cada extremo.
La tercera registra principal autenticado, decisión NACM, operación, datastore, payload, transacción, validación, commit y rollback. La cuarta conserva la lectura operacional posterior.
La quinta describe el recurso: snapshot de topología, ODU, señal cliente, granularidad, TPN, slots, ODTU, prioridad, restricciones, concurrencia y entradas de cálculo ODUflex. La sexta observa la red: cross-connect, alarmas, errores, óptica y tráfico.
Heng Lu formula la disciplina como primacía del código en funcionamiento. Aplicada aquí, no rebaja el documento. El documento gobierna el significado común; el código y el dispositivo gobiernan lo que aceptan y ejecutan; la observación gobierna lo que ocurrió. La cadena falla cuando un actor toma prestada la afirmación del siguiente.
Lo que las fuentes no prueban
Las fuentes congeladas demuestran la estructura propuesta, el estado de publicación y las fronteras de YANG, los datastores y el control de acceso. No prueban conformidad de una versión comercial, despliegue por un operador, reserva de un camino ni resultado medido.
Este Artículo no acusa a un proveedor ni estima adopción. Mantiene una conclusión operativa: un modelo puede contar con precisión sin tener autoridad para reservar. La automatización fiable conserva ambos hechos.
Sources
- Datatracker — revisión 20 de tipos Layer 1
- Datatracker — historial del documento
- Datatracker — expediente de publicación
- RFC 7950 — YANG 1.1
- RFC 8342 — arquitectura de datastores
- RFC 8341 — NACM
- RFC 6241 — NETCONF
- RFC 8040 — RESTCONF
- RFC 7062 — marco OTN GMPLS/ASON
- RFC 7139 — señalización GMPLS para OTN G.709
- RFC 8776 — tipos YANG de ingeniería de tráfico
- Lu Heng — primacía del código en funcionamiento
- Lu Heng — especificación inicial mínima
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
