Pozvánka na pražské setkání organizace IETF

O tom, jak vypadají a probíhají meetingy organizace IETF, tu psal nedávno kolega Ladislav Lhotka, který je jejich pravidelným účastníkem; kolega Lhotka je jedním ze dvou Čechů, kteří jsou podepsáni pod internetovými standardy, RFC dokumenty. Pokud by vám nestačil Láďův blogpost, podívejte se na Root.cz, kde dnes vyšel podrobnější popis toho, jak funguje IETF a co může čekat jeho návštěvníky v červenci v Praze. Tolik na úvod.

Před pražským meetingem IETF

Ve druhé polovině července bude Praha dějištěm 93. meetingu IETF, a stane se tak již potřetí v posledních osmi letech. CZ.NIC bude také podruhé za sebou jedním z hostitelů. To je jistě vyznamenání pro naše hlavní město, firmu i české pivo, zároveň se tím ale také české odborné veřejnosti nabízí možnost nahlédnout do kuchyně této významné mezinárodní organizace, která stojí za většinou internetových standardů a technologií.

Poslední výzva pro datové modely

Předseda pracovní skupiny NETMOD při IETF vyhlásil poslední výzvu (Working Group Last Call) pro tři Internet Drafty:

Tyto dokumenty obsahují specifikaci tzv. základních (core) datových modelů v jazyku YANG pro použití především s protokolem NETCONF. První z nich definuje konfigurační a stavová data síťových rozhraní a druhý k tomu přidává základní parametry IPv4 a IPv6. Třetí z dokumentů je pak zaměřen na IP směrování – kromě obecně potřebných parametrů vytváří i rámec, do něhož budou zasazeny budoucí datové modely směrovacích protokolů, route filtrů apod.

Zmíněné tři základní datové modely obsahují skutečně jen elementární parametry, které potřebuje téměř každé síťové zařízení. Jejich vývoj přesto nebyl úplně hladký, především proto, že jedním z hlavních požadavků byla kompatibilita s konfiguračními rozhraními (CLI) předních výrobců, tj. v první řadě Cisco Systems a Juniper Networks. Na tomto místě snad mohu přiznat, že jsem též přihřál naši polívčičku a při návrhu datového modelu pro směrování zohlednil i způsob konfigurace démona BIRD.

Právě proto, že jde o základní a široce použitelné věci, je velmi důležité, aby v těchto datových modelech nebyly žádné podstatné vady. Dovoluji si proto požádat všechny experty, kteří čtou tento příspěvek, aby se na uvedené dokumenty podívali. Pokud by zjistili nějaké nesrovnalosti, mohou je napsat buď přímo do mailing listu pracovní skupiny NETMOD, anebo jednoduše jako komentář k tomuto příspěvku – já bych je potom předal dále. Poslední výzva končí v pátek 30. listopadu, připomínky bude ale možné zapracovat i po tomto datu. Předem díky!

Ladislav Lhotka

Z IETF 84: standardizace konfiguračních dat

Během posledního meetingu IETF, který měl pořadové číslo 84 a konal se v kanadském Vancouveru, se výsledky mých „kmenových” pracovních skupin NETCONF a NETMOD objevily v zajímavé diskusi na širších fórech, konkrétně v mailing listu ietf@ietf.org, při jednání pracovní skupiny OPSAREA (Operations and Management Area), jakož i v kuloárních debatách.

Diskusi zahájil svým příspěvkem polský kolega Robert Raszuk. Pozastavil se nad tím, že ve specifikacích nových protokolů chybí schéma konfiguračních dat, a navrhl, aby všechna RFC povinně obsahovala oddíl s takovým schématem, protože bez něho si každá implementace vytváří svůj vlastní způsob konfigurace, který nemusí být s ostatními zrovna kompatibilní. Problém je to reálný, kdo by tomu nevěřil, ať si zkusí mezi sebou převést netriviální konfigurace směrovačů různých výrobců (včetně našeho BIRDa).

Navrhované řešení, tedy zavést toto jako povinnost, se ovšem setkalo s jednoznačným odporem. Robertovi se též dostalo doporučení, aby se seznámil s výsledky pracovní skupiny NETMOD, kde se již datové modely pro některé základní protokoly a subsystémy vyvíjejí.

V této souvislosti se ale ukázalo, že datové modely NETMOD tak docela nenaplňují vizi unifikace konfiguračních schémat. Jsou totiž poměrně pružné a umožňují definovat schémata v různých podobách, od odlišností v pojmenování objektů (klasickým příkladem jsou třeba jména síťových rozhraní) až po menší či větší rozdíly v logice a uspořádání konfiguračních dat. Důvody jsou nasnadě: Nelze očekávat, že přední výrobci směrovačů a jiných zařízení po zveřejnění datových modelů srazí paty a překopou svá konfigurační rozhraní, která si po léta hýčkají a školí na nich své zákazníky. Jistá míra pružnosti proto dává naději, že by se konkrétní implementace datových modelů mohly naopak přizpůsobit existujícím konfiguračním rozhraním. Lze pak ovšem očekávat, že nebude možné jednoduše vzít konfiguraci jednoho boxu a instalovat ji beze změn na obdobném zařízení jiného výrobce.

Toto je docela složité dilema, uvidíme, jak se věci vyvinou. Rozhodně by ale bylo dobré, kdyby se specifikace konfiguračního schématu staly součástí standardů aspoň pro nové protokoly – byť třeba nepovinně.

Ladislav Lhotka