Resumen

  • RFC 7570 define subobjetos genéricos ERO y RRO Hop Attributes para asociar atributos con un salto concreto.
  • El contenedor ERO es de tipo 35, tiene longitud variable y lleva uno o más TLV Hop Attributes. Su alcance es el subobjeto ERO identificador inmediatamente anterior, o los subobjetos de etiqueta asociados con ese salto.
  • La posición establece el alcance. El bit R importa las reglas de procesamiento obligatorio u opcional de RFC 5420; no define el significado del atributo.

El mecanismo práctico es una regla de adyacencia. La entrada coloca el subobjeto ERO Hop Attributes de tipo 35 después del objeto ERO que nombra el tramo buscado, o después de las etiquetas asociadas a ese salto. El nodo destinatario examina los TLV. Los demás saltos no reciben por ello la misma instrucción. El mecanismo genérico es un contenedor, no un permiso universal.

Cada documento que define un atributo debe indicar qué tipos de subobjeto ERO precedente son válidos, si el orden importa, cómo se interpreta y qué modificaciones se permiten. Esos documentos también deciden si el atributo es opcional, obligatorio, reportable o modificable. El bit R solo cambia la política de procesamiento: activado, el nodo examina los TLV conforme a las reglas obligatorias de RFC 5420, sección 5.2; desactivado, usa las reglas opcionales de la sección 4.2. No cambia el significado sustantivo del TLV.

El contenido no soportado o mal formado tiene consecuencias de establecimiento. Un nodo que encuentra un subobjeto ERO Hop Attributes que no soporta devuelve una Routing Error / Bad EXPLICIT_ROUTE PathErr, con el ERO truncado en el subobjeto infractor. RFC 3209 establece por separado que un subobjeto ERO no reconocido durante el procesamiento normal produce un error Bad Explicit Route Object, mientras que uno aún no encontrado se reenvía.

En cuanto a las banderas, solo se aplican las definidas como válidas en este contexto: las inválidas se ignoran silenciosamente, mientras que las desconocidas deberían provocar un Unknown Attributes Bit PathErr. La política local o el control de admisión aún pueden rechazar la solicitud, y el nodo puede modificarla cuando el procedimiento del TLV definidor lo permita. Por tanto, el poder de la entrada es capacidad de solicitar, limitada por el RFC definidor y por la autorización del nodo.

Hay dos vías de información. RFC 5420 trata los atributos de todo el LSP transportados en LSP_ATTRIBUTES o LSP_REQUIRED_ATTRIBUTES, que normalmente se informan mediante RRO Attributes. Un atributo señalado solo en ERO Hop Attributes normalmente se informa mediante RRO Hop Attributes, el contenedor RRO opcional de tipo 35. Un nodo puede informar que consideró un atributo de salto o informar un atributo adicional, pero la obligación de reportar cumplimiento debe estar en el documento que define el atributo. Sin esa definición, el establecimiento exitoso no demuestra que se ejecutó el comportamiento opcional.

RRO Hop Attributes es evidencia, no una prueba inmutable. Los nodos de tránsito normalmente lo reenvían sin cambios, pero el borde de un dominio puede podarlo o modificarlo por razones de confidencialidad o tamaño. Los nodos de entrada antiguos también pueden descartar información RRO desconocida. RFC 3209 describe RRO como información de ruta recopilada, útil para detectar bucles y diagnosticar, no como canal de autorización. RFC 7571 ofrece un ejemplo acotado: una solicitud de loopback OAM puede dirigirse a un nodo concreto y devolver el estado del loopback. Ese ejemplo no redefine el significado genérico de RFC 7570.

El beneficiario es un servicio que necesita un comportamiento en un tramo de tránsito específico. Los costes incluyen compatibilidad, espacio ERO/RRO, riesgo de fallo ante contenido obligatorio no soportado o mal formado, dependencias de orden y posible divulgación del estado de los saltos. El conjunto de fuentes no establece proveedores, despliegues, prevalencia, tasas de fallo, mediciones de crecimiento de mensajes ni resultados de clientes.

Fixtures de verificación a nivel de paquetes

  1. Construir un ERO que nombre el salto A y después un ERO Hop Attributes de tipo 35 con un TLV válido y R desactivado. Verificar que el alcance es A, no B, y que el establecimiento exitoso no demuestra ejecución opcional.
  2. Repetir con R activado sobre un subobjeto no soportado o mal formado. Verificar el PathErr Bad EXPLICIT_ROUTE y el truncamiento en el subobjeto infractor; no inferir comportamiento de un proveedor.
  3. Colocar el subobjeto antes del objeto ERO identificador o asociarlo con una secuencia de etiquetas incorrecta. Verificar las reglas del documento definidor, sin suponer validez genérica.
  4. Enviar por separado una bandera inválida y una desconocida. Verificar la ignorancia silenciosa de la primera y el comportamiento Unknown Attributes Bit especificado para la segunda.
  5. Comparar RRO Attributes de LSP_ATTRIBUTES/RFC 5420 con RRO Hop Attributes de un atributo enviado solo en ERO. Probar después un límite de dominio que pode el RRO y registrar que la ausencia de evidencia no demuestra que no hubo procesamiento.

Ruta de decisión del operador

Identificar primero el objeto ERO inmediatamente anterior y el documento del atributo. Confirmar después posición, orden, banderas válidas y reglas de modificación. Decidir si basta el procesamiento opcional; activar R solo cuando rechazar sea preferible a la falta de soporte silenciosa. Revisar política y admisión del nodo, y presupuestar tamaño y divulgación. Finalmente, definir qué informe RRO se requiere y cómo tratar su ausencia, poda o modificación. Si el beneficiario necesita prueba en un salto concreto, no sustituirla por un informe de todo el LSP ni por un Path exitoso sin más.

Fuentes