Resumen
- El 22 de septiembre de 2026, el grupo MPLS remitió draft-ietf-mpls-on-path-telemetry-flag-05 al IESG. Publication Requested es un estado de trámite, no aprobación del IESG, publicación como RFC, asignación de IANA ni prueba de despliegue.
- La marca P pide una postal a los nodos que entienden MNA y tienen activada la recopilación. No fija un conjunto universal de datos ni demuestra por sí sola que cada salto exportó.
- Una afirmación operativa necesita un recibo de activación a exportación que conserve alcance, política de marcado, capacidad y estado de los nodos, versión de plantilla, identidad de las postales, transporte, pérdidas, correlación y saltos ausentes.
La propuesta reduce la instrucción en el plano de datos. Un head-end añade una subpila MPLS Network Actions a un paquete seleccionado. Una marca P en formato D solicita que los nodos del trayecto generen postales. Las mediciones más ricas viajan fuera de banda.
El diseño ahorra espacio, pero no certifica el desenlace. El bit representa una petición; no es un acta sellada de todas las respuestas.
Publication Requested señala el siguiente responsable
Datatracker fecha la revisión 05 el 21 de septiembre. Al día siguiente, el estado del grupo pasó a Submitted to IESG for Publication y el del IESG a Publication Requested. Jim Guichard figura como area director responsable y action holder.
Esas etiquetas sitúan la siguiente decisión. No dicen que el texto haya sido aprobado. Aún no hay RFC derivado del borrador y, al congelar la evidencia, la tabla IANA de Network Action Flags Without Ancillary Data no contenía registros. El shepherd write-up solicita Proposed Standard, recoge apoyo amplio, ausencia de objeciones, dos declaraciones de IPR y ninguna implementación conocida.
El Opcode 1 de la MNA Sub-Stack ya existe bajo RFC 9994. PBT-M lo utiliza y pide además una nueva marca. La presencia del opcode no equivale a la asignación de P.
Un bit abre decisiones en cada nodo
La revisión 05 coloca una LSE Format D detrás de la LSE de acción. P opera hop-by-hop, no tiene ancillary-data LSE y usa U=0, de modo que un nodo que no reconoce la acción la omite. Un nodo capaz solo genera una postal si la recopilación está habilitada y exporta los tipos de datos elegidos localmente.
El head-end escoge qué paquete observar, pero no transporta un contrato completo de medición. Puede haber nodos incompatibles, compatibles pero desactivados, o activados con plantillas distintas. Un nodo también puede suprimir postales tras alcanzar su límite. El paquete del usuario sigue avanzando.
El borrador ordena marcar solo una fracción pequeña, nunca todos los paquetes, con un valor por defecto no superior a uno de cada 1.000 por flujo. Cada nodo limita la generación a una media de 1.000 postales por segundo y una ráfaga de 2.000. El tráfico que supera el límite se reenvía sin postal y queda contado.
La entrega del paquete y la integridad de la observación son resultados diferentes.
Cada postal es una declaración local
Una postal cuenta lo que un exportador vio bajo su configuración. El colector todavía debe determinar qué postales pertenecen al mismo paquete y qué secuencia de nodos representan.
Las postales pueden llegar desordenadas o perderse. Un TTL único puede resultar insuficiente cuando se insertan o retiran etiquetas. El texto considera un vector de TTL por LSE, identidad de nodo, identificador de flujo y marca temporal. Si dos paquetes simultáneos pueden compartir la clave disponible, la asociación es ambigua y debe descartarse.
Por eso, una ausencia no demuestra que el nodo no estuvo en la ruta. También puede indicar falta de soporte, recopilación desactivada, otra plantilla, supresión por límite, pérdida en la exportación, pérdida en el colector, cambio de ruta no observado o fallo de correlación.
El recibo de activación a exportación
| Campo | Evidencia que debe conservarse |
|---|---|
| Activación | marca P, entrada, política, versión del muestreador y tasa |
| Alcance | dominio de confianza, LSP esperado y ventana temporal |
| Nodos | identidad, capacidad PBT-M, estado activo e inventario de versión |
| Semántica | plantilla local, versión y tipos de datos seleccionados |
| Identidad | clave de paquete o flujo, secuencia y hora de exportación |
| Entrega | destino, transporte, enviados, pérdidas, supresiones y límites |
| Reconstrucción | regla de correlación, orden recibido, ambigüedades descartadas |
| Integridad | nodos esperados y recibidos, saltos ausentes y estado parcial |
| Seguridad | topes, excepciones, contadores excedidos y frontera de confianza |
No se propone otro formato de paquete. Es un recibo operativo compuesto por información del control plane, los exportadores y el colector. Permite mantener pequeña la instrucción y reproducible el significado del resultado.
El límite de confianza también importa
La marca P es mutable y no está autenticada. En la frontera de un dominio de confianza debe borrarse o rechazarse el paquete. Dentro, un nodo comprometido o mal configurado puede activar o quitar P. Los límites reducen la carga, pero no autentican la telemetría.
El borrador tampoco define un modelo YANG. No es una condena del protocolo, sino un límite práctico: descubrimiento de capacidad, activación, identidad de plantillas, salud de la exportación y política del colector requieren gestión explícita.
PBT-M usa tres LSE, 12 bytes, para una instrucción fija y deja los datos ricos fuera de banda. La formulación precisa es sencilla: el paquete lleva un disparador barato; la red y el colector llevan la prueba.
Fuentes
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