¿Respuesta breve? NPI... y lo digo cuando ya me he cansado de darle vueltas a documentos del IEEE este fin de semana. Hacéis unas preguntitas que vaya... con lo bien que vivía yo cuando os creíais todo lo que ponía en las transparencias :-)

He vuelto a bucear como he podido por 802.1Qbp y cómo quedó 802.1Q-2014, intentando entender por qué hace dos años dibujé esa trama así y hay cosas que están claras y cosas que yo no encuentro tan claras (pero tal vez sea porque me tenga que leer las 1800 páginas de seguido y entender todos los bloques bien, no lo sé).

El F-TAG está definido como os puse. Hay un Ethertype reservado para indicar su presencia y su TCI (Tag Control Information) contiene el flow hash y el TTL. Si veis tiene la misma pinta que el TCI para poner un VLAN ID y tal vez por eso lo coloqué inocentemente en el dibujo el primero, sustituyendo al B-TAG, pero NO he encontrado todavía nada claro en 802.1Q que me diga dónde $#@#¢ va ese tag. Se me habrá escapado, pero con las vueltas que le he dado diría que lo han dejado en el aire... Vamos a pensar que no es así. Os invito a buscarlo, vosotros que tenéis el cerebro más joven y ágil. A quien lo encuentr le cito en los agradecimientos de la transparencia para años posteriores.

Sí dice por ejemplo que el F-TAG es opcional, puede no estar, en cuyo caso el bridge puede calcular un hash a partir de la dirección MAC (y dan el algoritmo para hacerlo).

Por otro lado, yo diría que sí tiene que haber B-TAG. Me parece bien porque el IEEE va por la filosofía de mantener ASICs existentes y esos van a esperar lo primero de todo la etiqueta de VLAN. Tendré que modificar la figura para mantener lo primero el B-TAG, aunque sigo sin saber dónde poner el F-TAG. Digo que sí debe tener B-TAG porque dice en una parte el estándar:

"Flow filtering behavior is controlled by ISIS-SPB. To allow Bridges that support flow filtering to be used alongside Bridges that do not support flow filtering, ISIS-SPB requires that all Bridges at the SPT Domain boundary that advertise I-SIDs for an ECMP Base VID using flow filtering support F-TAG processing. Bridges that do not advertise I-SIDs for that Base VID are not required to support flow filtering. Therefore, network operators are able to upgrade selected bridges to support flow filtering and use flow filtering for selected VIDs without requiring the simultaneous upgrade of all bridges in the SPT Domain."

Es decir, yo entiendo de eso que en una VLAN del backbone puedes estar haciendo 802.1Qbp ECMP con F-TAG mientras que en otras hacer otra cosa, así que tiene que haber B-TAG (o al menos "puede" haberlo).

Sí dice claramente que debe emplearse SPBM:

"The second approach, ECMP, spreads traffic by employing multiple equal cost paths with a single VID. This approach is applicable only to SPBM."

con lo que digo yo que debe haber I-TAG.

Así que tenemos que debe haber I-TAG, parece que debería haber B-TAG y puede haber F-TAG. Lo que tiene más sentido es que el B-TAG vaya el primero, para mantener que sea donde está el VID del backbone (quien sabe, incluso con eso puedes meter en medio un switch con simple soporte de VLANs y nada más). El I-TAG digo yo que tiene que ir el último, pues su parte final son las direcciones MAC destino y origen de la trama del cliente, con lo que encajan con el payload y así no hay que reordenar bytes. Esto nos dejaría el F-TAG con la localización más simple entre el B-TAG y el F-TAG... pero no es más que "my best guess" :-(

Si alguien consigue un pcap con una trama de estas que avise :-)

Fijaos que hace unos años estuvieron discutiendo sobre si fusionar los tags:
http://www.ieee802.org/1/files/public/docs2011/bp-mackcrane-tag-format-0511.pdf

Uno podría, muy saludablemente, preguntarse si esto del 802.1Qbp está llegando a algún sitio, pues no sería el primer estándar que luego queda en agua de borrajas. Bueno, pues parece que Avaya tiene equipos que lo soportan (buscad 802.1Qbp en ese documento):
https://www.avaya.com/en/documents/avaya-virtual-services-platform-8000-series-dn7565.pdf

¿Lo venden? ¿Es competitivo y mejor que otras alternativas?

X

O sea, despeje usted la incógnita.

Yo lo que leo en los últimos años va mucho más por el lado de hacer la capa 2 sobre un core IP, es decir, las alternativas VXLAN/NVGRE, con lo cual no necesitas ECMP en Ethernet pues Ethernet se queda en el link entre switches capa 3 y el ECMP lo haces con IP. Cisco por ejemplo tira por ahí (aunque también es porque inicialmente Cisco tiraba por FabricPath, que es del tipo TRILL, con lo que es la competencia a SPB, lo cual tiene su lógica pues Cisco viene del mundo IP y de estándares del IETF más que del IEEE).

En fin, si habéis llegado hasta aquí, seguís mi razonamiento, entendéis la sopa de letras y demás, vais bien para nivel de máster :-)

La discusión queda abierta... ¿preferís ECMP en Ethernet o en IP y montar la LAN sobre IP?