Resumen

  • RFC 9892 reserva doce bits para el VID: 0x000 ignora el campo, 0xFFF está reservado y 0xFFE es el máximo explícito.
  • RFC 9895 obliga a implementar esa clasificación, aunque su sección de gestión usa 0x0000, 0xFFFF y 0x00010xFFFE; la búsqueda oficial no mostraba una errata al preparar este informe.

El ensayo parecía trivial: introducir en el controlador el primer valor que no cabe en doce bits. La respuesta «guardado» no resolvía nada. Había que preguntar qué valor conservó la base, qué bytes emitió el módem y qué regla instaló el router.

RFC 9895 define la extensión IEEE 802.1Q Aware Credit Window de DLEP. Permite que un módem asocie destinos, VLAN y PCP con ventanas lógicas de crédito. Una ventana puede compartirse o dedicarse; el router no envía tráfico hacia el módem sin saldo suficiente.

La clasificación procede de RFC 9892, y la contabilidad de RFC 9893. RFC 9895 dice que quien anuncia la extensión tipo 5 debe soportar todos los mensajes, Data Items y procesos aplicables de ambos textos. No son referencias decorativas.

El formato Ethernet de RFC 9892 divide un bloque de 16 bits: cuatro para NumPCPs y doce para VLAN Identifier. También fija los valores: cero (0x000) desactiva el VID como criterio, 0xFFF queda reservado y 0x0010xFFE son los identificadores explícitos posibles.

En cambio, la sección de gestión de RFC 9895 escribe cero como 0x0000, reserva 0xFFFF y permite hasta 0xFFFE. La última cifra requiere dieciséis bits. La frase aparece igual en el HTML y el XML del RFC Editor. La consulta pública de erratas no devolvía coincidencias en la fecha de comprobación.

El hallazgo tiene un límite. No es una corrección oficial ni una acusación contra los autores. Tampoco es evidencia de que un producto acepte esos valores. Es la constatación de que el rango administrativo publicado y el campo heredado no pueden ejecutarse literalmente a la vez.

La ruta de cable ofrece la interpretación más firme. RFC 9895 incorpora obligatoriamente el procesamiento de RFC 9892, y ese procesamiento sólo dispone de doce bits. Un VID explícito por encima de 0xFFE debe rechazarse antes de serializar. Ampliar el paquete no sería compatible; recortar sin avisar cambiaría el significado.

Ese recorte puede producir una regla válida pero equivocada. 0x1001 reducido a doce bits termina en VLAN 1. Un servicio que conserve el valor original mientras otro aplica una máscara crea dos verdades: el inventario muestra una intención imposible y el plano de datos ejecuta un destino real. La alarma no vendrá necesariamente del protocolo.

Otro sistema puede fallar tarde. El API acepta, la base persiste y el agente DLEP rechaza durante una actualización de sesión. Un tercer sistema puede convertir el número al tipo nativo del hardware. Estas son hipótesis de prueba, no incidentes observados. Precisamente por eso el control debe cubrir la cadena completa.

La prioridad entre clasificadores importa. Si Ethernet y Diffserv coinciden, RFC 9892 ordena usar VLAN/PCP. Una regla Ethernet nacida de truncamiento puede desplazar la ventana DSCP que el operador creía dominante. La extensión paralela de RFC 9894 no corrige ese orden.

Los comodines pueden mantener el servicio mientras rompen el aislamiento. RFC 9895 advierte que un comodín VID o PCP puede capturar flujos inesperados o posteriores a la configuración. Si la regla explícita no se instala y el comodín recoge el paquete, una prueba de conectividad será positiva, pero el tráfico habrá cambiado de ventana.

Tampoco basta con que ambos pares anuncien tipo 5. La negociación acredita soporte de la familia de extensión. El router puede tener menos colas o combinaciones que el módem, usar sólo un subconjunto o reiniciar la sesión, y debe mostrar la incompatibilidad al usuario. Nada de ello certifica el validador del portal o del controlador.

El conjunto de pruebas debe aceptar 0x001 y 0xFFE, rechazar 0xFFF, 0x1000, 0xFFFF, negativos y bits altos, y conservar el cero sólo con la semántica de ignorar VID. Para cada caso se comparan solicitud, almacenamiento, bytes emitidos, análisis del par, clasificador instalado y lectura posterior.

Después se cruzan Ethernet con DSCP, regla explícita con comodín, reconexión con reutilización de estado y exceso de ventanas con capacidad reducida. Todo rechazo debe ser visible. Toda normalización debe cambiar el resultado de la operación, no esconderse tras un código 200.

RFC 9893 sigue respondiendo a otra pregunta: cuándo puede el router enviar hacia la cola del módem. No arregla un selector erróneo ni acredita entrega. RFC 2475 separa de modo parecido clasificación, acondicionamiento, comportamiento por salto y servicio.

El registro DLEP de IANA asigna el código 5. Coordina la etiqueta de la extensión, no la ejecución de una API. La primacía del código operativo de Lu Heng pide evidencia local; la especificación inicial mínima reduce la superficie común; las capas de realidad impiden confundir publicación con resultado.

Una implementación local no puede reescribir el estándar. Puede, eso sí, aplicar el límite ejecutable, documentar su decisión, probarla y elevar el conflicto al sistema de erratas. La pregunta ejecutiva no es «¿soportamos Ethernet Credit?», sino «¿dónde muere el bit número trece, y queda constancia?».

Fuentes