Vlákno názorů k článku TRILL 4. část – Stav vývoje a alternativní řešení od Netman - Ze to neni cesta bych nerekl, to co...

Poslední odstavec je jenom jedna z mnoha možností :-)

V těch nejmenších sítích bude STP jistě poskytovat dobrou službu i nadále.

TRILL/SPB mají ale dlouhodobě šanci nahradit STP i třeba ve středně velkých sítích, protože konfigurační úsilí bude minimální (tj. stejné jako na klasických přepínačích) a přínosy podstatné. To, co v těchto sítích rozhodne, bude pozdější dostupnost levných ASICů s TRILLem/MAC-in-MAC pro komoditní L2 switche.

TRILL je implementačně mnohem jednodušším transportem L2 nežli realizace služby VPLS přes MPLS. Pro VPLS přes MPLS se musí se nastavit pseudowires, zajistit redundance a split-horizon, vymyslet případná hierarchie, oželet multipathing, zajistit hardware aj. A všechno to předpokládá již dříve implementovaný fungující MPLS backbone - tj. rozhodně ne běžnou situaci větší LAN sítě. Jde spíš o SP záležitost.

Teoreticky můžeme TRILL považovat za další technologii, díky které je možné službu VPLS realizovat (a to mnohem jednodušeji než přes technologii MPLS).

Ano, o složitosti návrhu a úspěchu v praxi si myslím totéž. Vždycky je to o nalezení vhodné hranice, jak složitý evoluční krok bude v praxi přijat a který už nikoliv, protože je příliš revoluční.

Nezapomeňme, že ta revoluční změna je v našem případě nahrazení rodiny STP něčím novým. Souboj protokolů bych proto viděl spíš v rovině "STP vs cokoliv novějšího" než "TRILL vs SPB". Zdá se mi, že TRILL a SPB na tom nejsou z hlediska složitosti tak dramaticky odlišně jako tomu bylo u ATM vs. Ethernet nebo u OSI vs. TCP/IP.

SPBM se mi líbí z pohledu maximalizace využití toho, co už je hotové a nasazené. Relativně jednoduchým rozšířením je možné vyřešit dost věcí (včetně STP) a věřím, že si najde svoje místo nasazení. Ze strany IEEE to je logický inkrementální krok dále.
(oproti tomu z SPBV jsem rozpačitý a těžko si představím např. jeho troubleshooting v praxi)

TRILL byl jako náhrada STP přímo navržen a slibuje oproti SPBM zejména lepší možnosti troubleshootingu.

V pozici vlastníka/tvůrce/správce sítě je nejtěžší rozhodnutí o nahrazení STP. Pokud už toto rozhodnutí padne, pak se už se nemusí tolik koukat na složitost konkrétního nahrazujícího protokolu, protože oproti STP jsou revoluční všechny skoro stejně. Spíš bych se při této volbě soustředil na to, abych co nejlépe dotáhl do konce původní myšlenku, proč jsem vůbec STP nahrazoval - abych měl stabilnější a lépe troubleshootovatelnou L2 síť. A v tomto slibuje TRILL být trochu napřed.

Jsou samozřejmě situace, kdy by mě vyšlo SPBM lépe:
- Už mám v síti dost switchů, které umí MAC-in-MAC
- SPBM switche budou výrazně levnější (např. pokud Broadcom, Marvell a ostatní výrobci obvodů budou schopni vyrobit levněji ASIC pro MAC-in-MAC než pro TRILL)
- ...

A při věštění budoucnosti bychom neměli vynechat ani tu vizi, že STP bude mít silný kořínek a vydrží s námi dalších 25 let, protože řadu menších LAN sítí jeho nestabilita tolik netrápí. TRILL/SPB by se prosazoval jen pomalu ve speciálních využitích...uvidíme :-)

:-)
Tohle doufání vyšlo ze srovnání vlastností obou návrhů nebo srovnáním zastřešující značky ? :-)

Ale vážně. Asi by bylo lepší, kdyby Radia Perlman, Donald Eastlake a další mohli vydat TRILL jako IEEE standard, protože tento standardizační institut má k Ethernetu a STP blíže.

Z různých důvodů (IEEE pochopitelně rozvíjí své existující standardy, různá otevřenost vývoje v obou organizacích aj.) to však bude jinak.

Tuším, jak zrádné může být posuzování protokolů dle "katalogových" vlastností, ale osobně mám radši řešení, které je úplnější i za cenu (únosně) větší složitosti návrhu. Má tak ambice vydržet s námi déle.
Třeba i více než 25 let, co už existuje STP :-)

Distribuční stromy se používají jen pro multi-destination rámce (neplést s multipathingem). Tj. pro broadcastové, multicastové a neznámé unicastové rámce.

Původní dotaz jsem pochopil jako multipathing nad známým unicastem, tj. k využití distribučních stromů nedojde a vždy se počítají nejvýhodnější cesty k cíli, nikoliv po větvích stromu.

Multipathing pro multi-destination (uff) rámce je ale i přesto možný tak, že se v síti vypočítá větší počet distribučních stromů s různými kořeny (normálně stačí jeden). Rozkládání zátěže (zase hashem) je pak mezi různými stromy.

Ta poznámka v draftu je směřovaná k situaci, kdy začnu multipathovat na neznámou unicastovou adresu, která se průběhu komunikace změní na známou (cílová stanice odpoví). V okamžiku přechodu ze stromového multipathingu na destination multipathing se skutečně může pár rámců předběhnout. Nicméně opět jde o okrajový výskyt, který je řešitelný, jak je v draftu psáno.

Je to opravdu stejné rozhodování jako v případě Etherchannelu (TRILL samotný toto řešení ponechal na standardu IEEE 802.1AX, na který odkazuje).

Tj. na prvku, na kterém je více stejně výhodných cest k cíli (představovaných několika hext-hopy) se na základě hashe hlavičkových položek zvolí jedna z cest. Pokud se vyberou ty správné hlavičkové položky, mělo by se dosáhnout toho, že v rámci jednoho toku se vybere vždy stejný next hop (a že pro jiný tok se s určitou pravěpodobností vybere next hop jiný). Zatím stejné jako pro Etherchannel.

To, že to je multihop, vůbec nevadí. Na každém dalším TRILL přepínači se toto rozhodnutí provede nezávisle znovu. Pokud jsou na zvolené cestě další rozvětvení, rámce se rozdělují mezi cesty jako by šlo o další Etherchannely. Pokud se cesty ještě před cílem spojí, nic se neděje. Jeden datový tok proběhne celou sítí vždy po jediné trase, není potřeba nijak synchronizovat switche mezi sebou.

Rámce se tedy mohou předběhnout jen v okamžiku rekonvergence sítě kdy se v mezičase, co už je rámec na cestě, nejvýhodnější cesty změní. To je ale problém i pro singlepathing v běžné Ethernetové síti bez TRILLu.