Resumen

  • RFC 1104 propuso discutir tres modelos de routing por políticas: distribución de información de rutas, filtrado o reenvío por paquete y asignación dinámica de ancho de banda, búferes y otros recursos. La contabilidad quedó relacionada, pero separada.
  • Una ruta disponible no probaba que un paquete superara el filtro. Una decisión local de reenvío no probaba trayecto ni entrega de extremo a extremo. Ninguna demostraba una reserva de capacidad o una imputación posterior válida.
  • La evidencia debía conservar por separado el estado de alcance, la disposición del paquete, la concesión de recursos y el registro histórico. Un único resultado llamado «política aplicada» borraba precisamente la información necesaria para auditar.

El plural estaba dentro del singular

La RFC 1104, firmada por H-W. Braun de Merit/NSFNET y fechada en junio de 1989, no presentó una arquitectura universal terminada. Quiso enumerar posibilidades y provocar una discusión sobre cómo escalar el routing por políticas. La ficha actual del RFC Editor muestra estado Unknown; el IETF Datatracker la sitúa en Legacy y sin rango formal en el proceso de estándares del IETF.

El documento separó lo que el lenguaje cotidiano juntaba. Una política podía seleccionar la información de rutas que cruzaba un límite. Otra podía inspeccionar cada datagrama. Una tercera podía repartir recursos dinámicos. La contabilidad añadía un historial capaz de alimentar decisiones futuras, pero no ejecutaba las anteriores.

Decir «el sistema aplicó la política» ocultaba cuál de esas máquinas había actuado. La pregunta correcta no era si había política, sino qué objeto cambió, quién tenía autoridad para cambiarlo y qué observador podía demostrarlo.

Distribuir alcance no era expedir un recibo al paquete

El primer modelo actuaba a escala de redes y Administrative Domains. Aceptar, usar, modificar o retener información de routing cambiaba el conjunto de destinos que una vista consideraba alcanzables. Era una intervención macroscópica.

RFC 1104 describió como ejemplo los controles históricos del acceso NSFNET: origen del vecino, identidad del dominio o AS, números de red anunciados y métricas reguladas mediante una base de políticas. Esa lista ya apareció como evidencia secundaria en el artículo de Sofia Ren sobre RFC 1074. Aquí no es tesis ni mecanismo de apertura.

La propia RFC marcó el límite: distribuir rutas no resolvía el filtrado por paquete y no impedía por sí solo tráfico malicioso introducido con source routing. Quitar una ruta podía eliminar una posibilidad desde cierta vista, pero no diagnosticaba todo descarte posterior. Mantenerla ofrecía una opción de reenvío, no una prueba de que el datagrama la utilizara o alcanzara el destino.

Por eso el registro de alcance necesita nombre del objeto, vecino, ámbito, versión de política y estado resultante. Una tabla de rutas no puede declarar que vio un paquete que nunca observó.

Un filtro sabía lo ocurrido en su propia puerta

El segundo modelo descendía al datagrama. Un router podía comparar campos disponibles con una regla y decidir localmente si reenviar o descartar. Esa granularidad llegaba a hosts o etiquetas de usuario donde la distribución de rutas solo distinguía redes y dominios.

La precisión exigía trabajo. RFC 1104 advirtió sobre el impacto en el rendimiento y sobre bases de políticas muy grandes que debían mantener consistencia. El control necesitaba demostrar qué versión estaba activa cuando llegó el paquete; una regla escrita en otro lugar o actualizada después no explicaba la decisión histórica.

Tampoco explicaba el camino completo. La RFC 1102 trató una cuestión diferente: construir gradualmente una ruta de política como secuencia de regiones administrativas. Superar un filtro en un punto no concretaba esa secuencia ni probaba el siguiente salto, el retorno o la entrega.

La afirmación defendible era pequeña: este paquete observado, en este equipo y momento, coincidió con esta regla y recibió esta disposición local. Todo lo demás necesitaba otra fuente.

Conceder capacidad afectaba a quien no la recibió

El tercer modelo administraba ancho de banda, búferes, circuitos y prioridad de colas. RFC 1104 lo consideró básicamente ortogonal a la distribución de routing, aunque reconoció interacciones.

Una ruta podía existir sin ancho de banda reservado. Un paquete admitido podía quedar esperando. También podía reservarse capacidad para un tráfico cuya conectividad fallaba más adelante. La autorización de circular y la provisión de medios para circular no eran un solo estado.

Además, el recurso era rival. Favorecer una clase podía retirar capacidad a otra. La asignación entre dominios planteaba entonces una cuestión política: ¿quién podía comprometer recursos mantenidos por otra administración? El texto exploró la dificultad; no acreditó una reserva concreta.

La escasez también admitía dos respuestas. Era posible gastar recursos en bases, inspección y cumplimiento o gastar para que la capacidad dejara de ser tan escasa. Que una regla pudiera programarse no demostraba que hacerla cumplir fuera la solución más barata.

La cuenta describía después y atribuía con cautela

RFC 1104 separó accounting del routing por políticas, aunque los relacionó. Una cuenta combinaba historia y regla: podía registrar ruta, volumen u otro uso a nivel de dominio, red, host o usuario y alimentar una decisión posterior.

El contador no concedía nada. Su cifra dependía de unidad, lugar, reloj y objeto de atribución. En un servicio formado por varios dominios, la medición interna de uno no necesariamente describía el servicio de extremo a extremo.

La RFC 1125 hizo explícitos más componentes de una política de cobro: unidad, base de medición, importe, pagador, contador válido y límites. Sus ejemplos no eran políticas oficiales. Sin embargo, mostraban que una cifra no contiene por sí misma la decisión de quién paga ni la autoridad para exigirlo.

La cadena debía conservar texto de política, estado cargado, acto de routing, filtrado o asignación, medición definida y decisión institucional. Saltar desde el contador hasta la responsabilidad convertía evidencia operativa en autoridad jurídica o comercial sin el eslabón correspondiente.

Las discrepancias eran datos, no ruido

Podía haber alcance y rechazo; admisión y falta de capacidad; reserva y ausencia de uso; uso medido y ninguna atribución válida. Esas combinaciones no hacían incoherente el modelo. Mostraban que sus controladores veían partes distintas.

Un campo «aplicado» habría borrado la causa. La ausencia de ruta parecería filtrado. El permiso parecería calidad de servicio. Una reserva parecería consumo. El consumo parecería deuda. El archivo útil debía conservar controlador, versión, hora, ámbito, ruta, disposición local, recurso concedido, unidad medida y acto posterior.

Fuentes