IPv6 – nechtěné dítě?

Na přelomu starého a nového roku se v „hlavním“ mailing listu IETF rozběhla výživná diskuse. Byla sice vyvolána bizarním návrhem IP verze 10, ve skutečnosti ale odráží všeobecnou frustraci ze šnečího tempa zavádění IPv6. John Klensin, jeden z praotců Internetu, zaujal překvapivě skeptické a sebekritické stanovisko. Podle něj proponenti IPv6 postupně ztrácejí na důvěryhodnosti: „Mnoho let jsme tvrdili, že IPv6 je připraveno na plošné nasazení a že všechny přechodové mechanismy jsou zvládnuty. Když se v praxi ukázalo, že to není tak úplně pravda, začali jsme strašit katastrofami, které měly vypuknout v souvislosti s jistými událostmi. K těmto událostem skutečně došlo, ale katastrofy se nedostavily.“

Celý článek

Jazyk YANG má novou verzi 1.1

Na konci srpna vyšel dokument RFC 7950, který obsahuje specifikaci jazyka YANG verze 1.1. Tento jazyk slouží k modelování konfiguračních a stavových dat a představuje základ pro bezpečnou vzdálenou správu síťových zařízení všeho druhu. Po skromných začátcích se YANG v posledních dvou letech docela pěkně rozšířil nejen v rámci IETF, ale i v jiných standardizačních institucích (IEEE, BBF) a také v průmyslu. Ukazuje se totiž, že standardní a strojově čitelné datové modely – tedy popis struktury dat, jejich datových typů a sémantických pravidel – jsou zejména pro operátory velkých a heterogenních sítí důležitější než konkrétní protokol, jímž se data přenášejí a editují.

Celý článek

Třicet let MINIXu

V březnovém čísle časopisu Communications of the ACM vyšel článek A. S. Tanenbauma „Lessons Learned from 30 Years of MINIX“. Pro ty, kdo nepamatují pohnuté události přelomu 80. a 90. let minulého století, připomenu, že MINIX byl v jistém smyslu přechůdcem Linuxu, a jeho autorem je právě (dnes již emeritní) profesor Andrew Tanenbaum.

Celý článek

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í.

Celý článek

Projekt NetIDE zahájen

Jedním z pojmů, které dnes hýbou telekomunikačním světem, jsou softwarově definované sítě (SDN). Tomuto tématu jsem už před časem věnoval příspěvek, takže jen krátce připomenu, že koncept SDN vychází z modelu sítě složené z „hloupých“ přepínačů a centrálního řídícího systému zvaného kontrolér.

Celý článek

Pomsta za Internet?

Síťové sekci konference Intel European Research and Innovation Conference 2013 (program) jednoznačně vévodily dvě zkratky: SDN (Software Defined Networking) a NFV (Network Functions Virtualization). O SDN jsem už na tomto místě psal a na další příspěvek se chystám v souvislosti s účastí CZ.NIC v FP7 projektu NetIDE.

O virtualizaci síťových funkcí přednášeli především zástupci velkých telekomunikačních operátorů (Telefónica, Verizon) a firem, které jim navrhují infrastrukturu a dodávají služby. Mně osobně daly jejich příspěvky možnost nahlédnout pod pokličku sítí 4G LTE, o nichž, přiznám se, jsem toho dosud mnoho nevěděl. Ne že bych byl teď o mnoho moudřejší, ale jeden základní dojem jsem si přece jenom odnesl – tyhle sítě jsou v porovnání se standardním Internetem pekelně složité. Už jen ta záplava zkratek, namátkou: OSS, BSS, HSS, MME, PCRF, OTT, BRAS, SGSN, GGSN, VAS … Virtualizace je pak celkem pochopitelně jednou z cest, jak tento moloch zvládnout.

Přemýšlel jsem o tom, kde se ta složitost vlastně bere. Zčásti jde jistě na vrub známých nedostatků v reálném Internetu, jakými jsou třeba nefungující multicast či chabá podpora mobility. Hlubším důvodem je ale podle mého známý end-to-end princip, na němž jsou protokoly TCP/IP postaveny, tedy v podstatě hloupá a ne zcela spolehlivá síť, jež funguje díky tomu, že pokročilejší funkce jsou soustředěny v koncových stanicích. Je jasné, že v takové best-effort síti je obtížné nabízet zákazníkům diferencované služby a podle toho je pak také kasírovat.

Když tedy technologičtí experti předestírají vize budoucího Internetu jakožto sítě chytrých telefonů a jiných mobilních zařízení, musíme si uvědomit, že se nejedná jen o osvobození od kabelů, ale dost možná taky o podstatné změny v architektuře globální sítě – bude to vlastně ještě Internet, jak jej dnes známe?

Ladislav Lhotka

Je email mrtvý?

Nedávno vystoupil v Hyde Parku na ČT24 Luis Suarez, ovšem nikoliv útočník FC Liverpool, ale, jak pravil moderátor, vizionář ve službách IBM. Jeho vize je v kostce tato: zahodit email a pro veškerou komunikaci používat sociální sítě. Jsem dalek toho, abych panu Suarezovi takový systém rozmlouval, pokud mu (zatím) funguje, těžko však mohu souhlasit s tím, když je prezentován jako obecný návod pro širokou veřejnost.

Stinné stránky sociálních sítí jsou již dostatečně známé. Pomineme-li ty, které si uživatelé sami způsobují svým neopatrným chováním, nejvážnějším problémem je fakt, že se profily osob a skupin, jakož i veškerá jejich komunikace, soustřeďují v rukou provozovatele sociální sítě. Ten pak z těchto dat může zajisté těžit informace pro různé účely, v lepším případě komerční. Email je naproti tomu stále velmi distribuovaná služba a každý její uživatel má možnost, aspoň principiálně, rozhodovat o tom, komu svá data a texty poskytne.

Zdá se však, že pro mnoho uživatelů se email stává docela obtížným břemenem, a tak snáze podléhají představě, že v silu sociální sítě jim bude líp. Možná si řeknete: no jasně, spam. Já si ale myslím, že běžný spam je docela dobře řešitelná záležitost a pro průměrného uživatele představuje jen okrajový problém.

Mnohem větším uměním je vyrovnat se s tím, co zbude po odfiltrování spamu, tedy se zprávami, které lze v podstatě považovat za legitimní. Znám řadu lidí, třeba i jinak dobře organizovaných, kteří s sebou jako kouli na noze táhnou inbox zvíci tisíců zpráv. Podle svého naturelu se tím pak zbytečně stresují anebo nereagují ani na důležité maily (případně obojí).

Dostupné technologie jim s tím bohužel příliš nepomohou. Běžní mailoví klienti typu GUI jsou zbytnělé kusy softwaru, které při práci s opravdu velkými mailovými archivy buď rovnou kolabují anebo se nesnesitelně zpomalí. Nástroje pro klasifikaci zpráv, vyhledávání apod. také obvykle nejsou na úrovni doby. Je charakteristické, že uživatelsky nejpříjemnější a technologicky nejpokročilejší jsou zase centralizované služby typu GMail. Jiné alternativy, jako je například projekt Notmuch, jsou stále v počátcích a pro řadového uživatele jen obtížně použitelné.

Otázka, jíž je nadepsán tento příspěvek, je možná sugestivní a odpověď je zatím naštěstí záporná. Zatím… Nejde snad tolik o mail jako takový, ale o princip distribuované aplikace, kterou nemá nikdo konkrétní plně v rukou. Mně se do sila nechce.

Ladislav Lhotka

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: Interface to the Routing System

Novou zkratkou, kterou bylo často slyšet v kuloárech vancouverského meetingu IETF, je IRS. Cílem této iniciativy je, jak už název napovídá, standardizované rozhraní pro přístup do „střev“ IP směrovačů. Toto rozhraní má zprostředkovat externím softwarovým aplikacím poměrně detailní náhled do stavu směrovacího subsystému, ale také umožnit přímé zásahy do směrování a modifikace směrovacích tabulek (RIB) a dalších datových struktur, například LFIB (pro MPLS) a multicast RIB.

Více informací o IRS lze prozatím získat ze dvou Internet draftů:

Oba dokumenty lze těžko obvinit z přílišné skromnosti, pokud jde o šíři očekávaných aplikací. Autoři předpokládají nasazení IRS jak pro monitoring a diagnostiku směrování, tak i pro implementaci nejrůznějších administrativních politik v oblastech jako QoS, bezpečnost, diferencované nakládání se zákazníky apod., prostě všude tam, kde standardní konfigurace a směrovací protokoly (údajně) nestačí.

Prezentace IRS při jednání pracovní skupiny Routing Area vyvolala velmi bohatou diskusi. Reakce byly většinou pozitivní a podpůrné, kritické komentáře upozorňovaly hlavně na nebezpečí přílišné šíře záběru – jak se pěkně anglicky říká: „boiling the ocean“.

IRS se má od existujících metod interakce se směrovacím systémem (CLI, SNMP, IPFIX, NETCONF) lišit možností rychlého přístupu k detailním informacím o stavu systému a možností operativních softwarově řízených zásahů. První z uvedených dokumentů však při analýze vhodnosti protokolu NETCONF coby mechanismu pro realizaci IRS vycházel v řadě ohledů ze zastaralých anebo přímo nesprávných informací – NETCONF byl pak na jejich základě zavržen. Tyto nedostatky byly v diskusi také zmíněny a aktivisté IRS přislíbili, že se k výchozí analýze ještě vrátí a použití NETCONFu a jeho datových modelů znovu zváží.

Moje osobní dojmy jsou zatím smíšené. Samotná idea IRS jako mechanismu pro přístup ke směrovacím datům je v pořádku, trochu mne ale dráždí jeho avizované použití. Vychází totiž z předpokladu, že směrování v Internetu lze optimalizovat aktivním řízením routerů z nějakého „inteligentního“ centra. Dosavadní zkušenosti mne přesvědčují, že se v takových případech výkon sítě často spíše zhorší.

Otázky IRS jsou intenzivně diskutovány v konferenci  irs-discuss. Pokud půjde vše podle předpokladů, bude se na příštím meetingu IETF 85 v Atlantě konat zasedání typu BoF (Birds of a Feather) a z něj by následně mohla vzejít nová pracovní skupina IRS při IETF.

Ladislav Lhotka

Z IETF 84: SNMP data pod křídla NETCONFu?

Můj druhý postřeh z meetingu IETF 84 se také týká protokolů a nástrojů pro síťový management. Zatímco minulý příspěvek byl věnován konfiguračním datům, dnes bych se rád zmínil o jedné diskusi týkající se stavových dat, která jsou pro efektivní správu síťových zařízení také velmi důležitá. Čím se liší od těch konfiguračních? Rozdíl můžeme ukázat na jednoduchém příkladu IP adresy. Ta může být pro dané rozhraní buď statická, a pak je zapsána někde v konfiguračních datech, anebo se získává pomocí DHCP a její aktuální hodnotu může správce zjistit ze stavových dat. Za stavová data se obvykle považují i různé statistické čítače, kupříkladu počty bajtů přijatých a odeslaných přes dané rozhraní.

Pro práci s oběma typy dat jsou k dispozici dva konkurenční protokoly: SNMP a jeho mladší bratranec NETCONF. Pokud jde o konfigurační data, hovoří vše celkem jasně pro NETCONF, SNMP se v této oblasti neosvědčil a dnes se prakticky nepoužívá. U stavových dat je ale situace do velké míry opačná a SNMP tu zatím jednoznačně vládne. Síťovým operátorům už se ovšem dosti zajídá spravovat sítě pomocí dvou různých protokolů – a začínají se hlasitě ozývat.

Diskuse na toto téma propukla na IETF 84 poněkud nečekaně během jednání pracovní skupiny OPSAWG, když byl na programu Internet draft draft-schoenw-opsawg-vm-mib-01, který definuje část databáze SNMP MIB se stavovými daty pro virtuální počítače s hypervizorem. Rozbuškou však nebyl tento celkem nevinný dokument, ale osoba přednášejícího: byl jím Jürgen Schönwälder, který je jednou z vůdčích figur stojících za návrhem protokolu NETCONF. Dotaz z pléna zněl zhruba takto: „Jestli to s NETCONFem myslíte vážně, proč nás pořád zásobujete novými daty pro SNMP a neimplementujete raději stejná data v NETCONFu?“ Většina diskutujících se pak skutečně přiklonila k názoru, že by bylo velmi prospěšné toto schizma postupně odstranit a mít všechna stavová data k dispozici prostřednictvím NETCONFu.

To se snadno řekne, ale hůře udělá. Převod všech definic objektů z databáze MIB (zapsaných v jazyku SMIv2) na datový model pro NETCONF (v jazyku YANG) je sice možný, vzhledem k vysokému počtu MIB objektů je to ale práce pro vraha, a tak se do ní nikomu nechce. Druhou alternativou, která se již také testovala, je proto automatický převod. Pro tento účel dokonce existuje specifikace v RFC 6643, jehož autorem je shodou okolností rovněž Jürgen Schönwälder.

Jenže, jak víme i z jiných případů, výsledky strojového překladu nebývají zrovna ideální. V daném případě se naráží jednak na některé nekompatibility mezi jazyky SMIv2 a YANG (příkladem je rozdílný způsob indexace objektů v databázi), ale také na problém převodu důležitých informací zapsaných v MIB modulech volným textem – doplňujících popisů a implementačních instrukcí.

Momentálně tedy převládá názor, že automatický převod lze použít ad hoc v případě akutní potřeby přístupu k MIB datům pomocí protokolu NETCONF. Z dlouhodobého hlediska bude ale asi nezbytné podstoupit martyrium spojené s ruční konverzí. Vypadá to tedy, že internetová komunita má v této oblasti o práci postaráno na řadu příštích let.

Ladislav Lhotka