Menjava internetnih usmerjevalnikov

VPRAŠANJE
3.	Naročnik v poglavju 3.2.4
1.	v razdelku »Število in vrsta vrat, širljivost« zahteva
1.	»Podpora za skladanje (stacking)« ter
2.	V razdelku »Redundanca« zahteva
1.	»arhitektura dveh stikal mora v povezavi z redundantno priključenimi napravami (LACP) omogočati posodabljanje programske opreme posameznega stikala (ISSU In-service Software Upgrade) na način, da med nadgradnjo ne pride do prekinitve delovanja storitev oziroma opaznega izpada podatkovnega prometa v omrežju (nemoteno delovanje storitev)«
Komentar:
Klasični stacking združi procesorske ravnine (control plane) stikal, kar pomeni, da programska napaka na enem stikalu lahko povzroči izpad celotnega sklada (visoko tveganje za celotno omrežje). Sodobne platforme visoke razpoložljivosti namesto tega uporabljajo napredne tehnologije za večsmerno združevanje povezav, kot je MC-LAG (Multi-Chassis Link Aggregation). Ta tehnologija zagotavlja popolnoma neodvisno delovanje procesorjev posameznih stikal (kar drastično poveča stabilnost), hkrati pa preko standardnega protokola LACP (802.3ad) omogoča izvedbo t.i. sekvenčne nadgradnje brez prekinitve delovanja (Rolling Upgrade). Med ponovnim zagonom posameznega stikala priključene naprave v milisekundah strojno preusmerijo celoten podatkovni promet na drugo aktivno stikalo, s čimer se v celoti doseže naročnikov cilj nemotenega delovanja storitev med vzdrževalnimi deli. 
Strogo vztrajanje pri specifičnih terminih »stacking« in »ISSU« ne prinaša tehnične prednosti, temveč naročnika omejuje pri izbiri sodobnejših in varnejših platform ter krši načelo zagotavljanja konkurence med ponudniki (ZJN-3).
Vprašanje:
Ali naročnik z namenom spodbujanja konkurence in pridobitve tehnološko napredne rešitve potrjuje, da bo kot ustrezno priznal opremo, ki visoko razpoložljivost, redundanco, aktivno-aktivno združevanje povezav (LACP) ter posodabljanje programske opreme brez opaznega izpada podatkovnega prometa zagotavlja preko tehnologije MC-LAG (Multi-Chassis Link Aggregation) ali enakovredne tehnologije za porazdeljeno visoko razpoložljivost, ne glede na to, ali naprava podpira klasično fizično skladanje (hardware stacking) in ISSU protokol?


ODGOVOR NAROČNIKA:
Naročnik pojasnjuje, da je tehnologija MC-LAG (Multi-Chassis Link Aggregation) oziroma MLAG skladno s poglavjem 3.2.4 razpisne dokumentacije (razdelek Redundanca) že sedaj prepoznana kot ustrezna in dopustna. Naročnik je namreč izrecno navedel, da sta stikali lahko povezani bodisi kot enoten logični sistem (Stacking) bodisi preko tehnologij porazdeljenega nadzora in združevanja povezav (npr. MLAG, VSF, VLT ali funkcionalno enakovredna tehnologija).
Skladno z navedenim naročnik potrjuje, da bo kot ustrezno priznal rešitev, ki visoko razpoložljivost, redundanco, aktivno-aktivno združevanje povezav (LACP) ter posodabljanje programske opreme brez opaznega izpada prometa zagotavlja preko tehnologije MC-LAG/MLAG ali enakovredne tehnologije, pri čemer se nadgradnja stikal izvede sekvenčno (angl. Rolling Upgrade), na način, da je ves čas zagotovljeno nemoteno delovanje storitev v omrežju.
Posledično fizična podpora za klasično strojno skladanje (hardware stacking) in specifičen ISSU protokol na sami napravi nista eliminacijski zahtevi, v kolikor ponujena tehnologija (npr. MC-LAG/MLAG) v celoti zagotavlja redundanco brez enojne točke odpovedi ter posodobitev programske opreme brez opaznega izpada podatkovnega prometa. Naročnik ob tem opozarja, da mora ponujena rešitev ne glede na uporabljeno tehnologijo (MLAG ali Stacking) še vedno v celoti izpolnjevati zahteve iz kosovnice (točka D), ki določa medsebojne povezave s pasivnimi direktno povezljivimi bakrenimi kabli (DAC) hitrosti 100 Gb (QSFP28) s skupno medsebojno prepustnostjo stikal vsaj 200 Gb. Preostali pogoji iz razpisne dokumentacije ostajajo nespremenjeni.

VPRAŠANJE

1.	Naročnik v poglavju 3.2.2
1.	v razdelku »Upravljanje, avtomatizacija in odprti vmesniki« zahteva
1.	podporo za REST API. 
2.	podporo za NETCONF in/ali RESTCONF
3.	podporo za standardne podatkovne modele

2.	v razdelku »Avtomatizacija« pa dopušča
1.	centralizirano upravljanje konfiguracij preko standardnih odprtih vmesnikov (NETCONF, REST API, RESTCONF ali enakovredne)

Komentar:
Sodobni varnostni sistemi in omrežne naprave vodilnih svetovnih proizvajalcev namesto protokolov NETCONF/RESTCONF primarno uporabljajo izjemno zmogljive in varne REST API vmesnike s strukturiranimi podatkovnimi modeli (npr. JSON/YAML), ki omogočajo identično stopnjo avtomatizacije, integracije v centralne sisteme in programabilnost upravljanja. Trenutna dikcija strogo omejuje nabor ponudnikov in naročniku onemogoča pridobitev tehnološko naprednejših rešitev priznanih proizvajalcev, ki dosegajo enak cilj prek REST API vmesnikov.
Vprašanje:
Ali naročnik potrjuje, da bo kot ustrezno in enakovredno priznal tudi opremo, ki omogoča celovito upravljanje, konfiguracijo in avtomatizacijo preko REST API vmesnika s strukturiranimi podatkovnimi modeli, brez uporabe NETCONF in/ali RESTCONF?


ODGOVOR NAROČNIKA:
Naročnik se ne strinja z navedbo, da predmetna zahteva onemogoča pridobitev tehnološko naprednejših rešitev. Namen zahteve ni omejevanje posameznih proizvajalcev ali tehnoloških rešitev, temveč zagotavljanje dolgoročne interoperabilnosti, odprtosti in neodvisnosti upravljanja omrežne infrastrukture.
RTV Slovenija za upravljanje, nadzor in avtomatizacijo omrežne infrastrukture uporablja in razvija lastne rešitve, ki v pomembnem delu temeljijo na odprtokodnih tehnologijah in standardiziranih vmesnikih. Naročnik zato ne želi biti pri avtomatizaciji in upravljanju ključne omrežne infrastrukture vezan izključno na lastniška upravljavska orodja, licenčne produkte ali proizvajalčeve specifične programske vmesnike.
Zahteva po REST API ter NETCONF in/ali RESTCONF je določena z namenom omogočanja integracije opreme v obstoječe in prihodnje sisteme naročnika, razvoja lastnih avtomatizacij ter uporabe standardnih orodij in podatkovnih modelov neodvisno od posameznega proizvajalca opreme.
REST API je v razpisni dokumentaciji že zahtevan in ga naročnik šteje za pomemben upravljavski vmesnik. Vendar implementacija REST API, ki je lahko specifična za posameznega proizvajalca, sama po sebi ne zagotavlja enake stopnje standardizirane in proizvajalčevo neodvisne interoperabilnosti, zaradi katere naročnik zahteva tudi podporo NETCONF in/ali RESTCONF.
Naročnik zato zahteve ne spreminja. Ponujena oprema mora poleg zahtevanega REST API podpirati najmanj enega od standardiziranih upravljavskih vmesnikov NETCONF ali RESTCONF, skladno z zahtevami razpisne dokumentacije. 



VPRAŠANJE

2.	Naročnik v poglavju 3.2.3
1.	v razdelku »Zahtevana zmogljivost,  možne nadgradnje« zahteva
1.	najmanj 64 GB sistemskega pomnilnika za stabilno obdelavo IPv4 in IPv6 BGP usmerjevalnega seznama (polna BGP tabela / full BGP table)
2.	podpora za najmanj 3 milijone IPv4 ali 1 milijon IPv6 usmerjevalnih vnosov v podatkovni ravnini (FIB) ter najmanj 20 milijonov usmerjevalnih vnosov v kontrolni ravnini (RIB) brez uporabe posebnih optimizacij, delitve tabel ali zmanjšanja zahtevanih IPv4/IPv6 tabel.
Komentar:
Zahtevani številčni parametri fiksno določeni na podlagi tradicionalnih arhitektur hrbteničnih usmerjevalnikov, se neupravičeno omejuje konkurenca in izloča sodobne, visoko optimizirane sisteme, ki dosegajo enak ali višji nivo stabilnosti in prepustnosti prometa. 
Sodobne platforme vodilnih svetovnih proizvajalcev uporabljajo dinamično upravljanje pomnilnika (Dynamic Memory Allocation), kjer ni programskih omejitev za RIB table. Zaradi učinkovitejšega zapisa poti v operacijskem sistemu te naprave za stabilno obdelavo več polnih internetnih BGP tabel hkrati ne potrebujejo fiksno 64 GB RAM-a ampak drastično manj. Prav tako se v tovrstnih sodobnih arhitekturah za doseganje "wire-speed" prepustnosti prometa uporablja hibridni model, kjer se seje takoj po prvem paketu strojno pospešijo na namenskih mrežnih procesorjih, kar odpravlja potrebo po vnaprejšnjem polnjenju milijonov statičnih vnosov neposredno v strojno FIB tabelo.
Vprašanje:
Ali naročnik z namenom spodbujanja konkurence in pridobitve tehnološko napredne rešitve potrjuje, da bo kot ustrezno priznal opremo, ki dokazano omogoča polno podporo in stabilno hkratno obdelavo polnih internetnih BGP tabel (IPv4 in IPv6), ter zagotavlja strojno pospeševanje prometa (hardware offloading), ne glede na specifično količino fizičnega pomnilnika (RAM) in teoretične metrične omejitve vnosov RIB/FIB, v kolikor proizvajalec opreme uradno jamči za stabilnost in zmogljivost delovanja v takšnem okolju? V kolikor bo naročnik kot ustrezno priznal opremo z zgornjimi prilagoditvami vas prosimo, da nam sporočite količino »internet exchange« povezav, ki jih planira naročnik imeti.


ODGOVOR NAROČNIKA:
Naročnik pojasnjuje, da predmet javnega naročila predstavlja osrednjo kritično internetno robno infrastrukturo RTV Slovenija, ki se nabavlja za dolgoročno obdobje uporabe. Minimalne tehnične zahteve so določene z namenom zagotavljanja determinističnega delovanja, dolgoročne stabilnosti, varnostne rezerve ter skalabilnosti omrežne infrastrukture v specifičnem produkcijskem okolju naročnika.
Fizične strojne zmogljivosti (kot sta fiksna kapaciteta FIB/RIB tabel na ravni strojne opreme in zadostna količina sistemskega pomnilnika) naročniku jamčijo stabilno delovanje naprave tudi ob ekstremnih konicah prometa, izrednih varnostnih dogodkih (npr. napadih z onemogočanjem storitev – DoS/DDoS z generiranjem unikatnih IP tokov) ali ob nadaljnji rasti globalnih internetnih usmerjevalnih tabel. Programske optimizacije, hibridni modeli procesiranja prometa po prvem paketu (hardware offloading) ali dinamično upravljanje pomnilnika v vseh produkcijskih pogojih ne morejo zagotoviti enake stopnje predvidljivosti in varnosti kot robustna strojna zasnova, zato jih naročnik ne prepoznava kot enakovredne zahtevanemu standardu »brez uporabe posebnih optimizacij«.
Z namenom zagotavljanja transparentnosti in enakopravne obravnave ponudnikov naročnik posreduje podatke o omrežnem okolju: RTV Slovenija ima trenutno vzpostavljeni polni BGP seji do dveh neodvisnih ponudnikov internetnega dostopa (ISP) ter redundantno dvostransko povezljivost (dual-homing) v vozlišče SIX (Slovenian Internet Exchange). Nova oprema mora biti dimenzionirana tako, da že ob vklopu stabilno in sočasno sprejme ter obdeluje več polnih internetnih usmerjevalnih tabel (Full BGP Table) iz vseh navedenih virov, hkrati pa zagotavlja zadostno strojno rezervo za načrtovan prehod na več 100 Gb/s povezav in nadaljnjo širitev zunanje povezljivosti v prihodnosti.
Zaradi navedenega zahteva po najmanj 64 GB sistemskega pomnilnika in specificiranih zmogljivostih tabel predstavlja objektivno utemeljeno tehnično potrebo naročnika za pričakovano rast in varno obratovanje kritične infrastrukture skozi celotno življenjsko dobo opreme.
Glede na vse navedeno naročnik ne spreminja zahtev iz razpisne dokumentacije. Tehnične specifikacije v poglavju 3.2.3, vključno z minimalno količino fizičnega pomnilnika (64 GB RAM) ter zmogljivostmi RIB in FIB tabel, ostajajo nespremenjene.

VPRAŠANJE
Ali je ustrezno, če predložimo obrazec OBR-6A preveden v angleški jezik, tako da vsebina izjave vsebinsko in pomensko ustreza naročnikovemu v naprej pripravljenemu obrazcu?

ODGOVOR
Da. Predložitev obrazca v angleškem jeziku je ustrezna. Kot je navedeno v točki 4.1.2 razpisne dokumentacije, se dokumenti iz točke 4.2.7 lahko predložijo v angleškem jeziku, pri čemer mora vsebina izjave vsebinsko in pomensko v celoti ustrezati naročnikovemu vnaprej pripravljenemu obrazcu.