Dywagacje o ASIC-ach i aplikacjach

Problemy i dyskusje z zakresu rozwiązań i technologii Data Center

Moderatorzy: mikrobi, aron, garfield, gangrena, Seba

Wiadomość
Autor
lbromirs
CCIE
CCIE
Posty: 3936
Rejestracja: 30 lis 2006, 08:44

Dywagacje o ASIC-ach i aplikacjach

#1

#1 Post autor: lbromirs » 02 kwie 2017, 21:00

gangrena pisze:
xal pisze:Ale ja o ACI nic nie wspominałem :-P
Tak, nie wspominałeś, ale przytoczyłeś opinie, które nawet mocniej odnoszą się do platformy, którą wspierasz. ;)
Przestańcie uprawiać bezsensowną dyskusję :) VMWare podjął decyzję o usunięciu API, co wg. gangreny jest oznaką większej otwartości. Koniec dyskusji :)
gangrena pisze:Vide programowalne ASIC z Barefoot Networks.
Programowalne ASICi to już od 15-16 lat się robi. I nie, to nie Cisco zaczęło, ale Cisco dzisiaj produkuje dwa najszybsze i najbardziej skalowalne - QFP i nPower X1. Zresztą, za rogiem jest kolejny. To na co *mógłbyś* zwrócić uwagę, to zopensource'owanie takiego ASICa np. w projekcie OpenCompute i możliwość zamawiania sobie whiteboxów od dajmy na to 100 sztuk w górę (czyli przez potencjalnego zwykłego śmiertelnika) - bo to faktycznie przybliży wszystkich maniaków SDNa na sprzęcie do realnych zastosowań z (być może) realną skalowalnością. To co dzisiaj oferuje sprzętowo wsparcie dla P4 czy OpenFlow to żart. Wszyscy w związku z tym tłuką nakładki a potem tradycyjnie rozbierają per-pakiet usługi :)
gangrena pisze:U mnie na tapecie workbook do CCIE SP i security w DC.
Właśnie, zamiast gadać głupoty i chodzić po forach to byś się za workbook zabrał. Zrobię BeGiePa bez SDNów, opowiem o eMPeeLeSach i już będzie Twoja kolej - masz tylko dwa tygodnie :)


===========
EDIT by gangrena:
Dywagacje na bazie dyskusji: viewtopic.php?f=59&t=21744

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2342
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: Cisco Nexus 1000v vs VMware vDS

#2

#2 Post autor: gangrena » 02 kwie 2017, 22:24

lbromirs pisze:VMWare podjął decyzję o usunięciu API, co wg. gangreny jest oznaką większej otwartości. Koniec dyskusji :)
Jak już mamy się tak głaskać przeinaczaniami, to według lbromirs większa otwartość, to tylko w stronę Cisco. :D
lbromirs pisze:Programowalne ASICi to już od 15-16 lat się robi. I nie, to nie Cisco zaczęło, ale Cisco dzisiaj produkuje dwa najszybsze i najbardziej skalowalne - QFP i nPower X1. Zresztą, za rogiem jest kolejny. To na co *mógłbyś* zwrócić uwagę, to zopensource'owanie takiego ASICa np. w projekcie OpenCompute i możliwość zamawiania sobie whiteboxów od dajmy na to 100 sztuk w górę (czyli przez potencjalnego zwykłego śmiertelnika) - bo to faktycznie przybliży wszystkich maniaków SDNa na sprzęcie do realnych zastosowań z (być może) realną skalowalnością. To co dzisiaj oferuje sprzętowo wsparcie dla P4 czy OpenFlow to żart. Wszyscy w związku z tym tłuką nakładki a potem tradycyjnie rozbierają per-pakiet usługi :)
Programowalność nie równa się programowalności. Gratuluję Cisco QFP i X1, co nie zmienia trendu korzyści uruchamiania usług sieciowych na x86. TCAM jest hamulcowym.
lbromirs pisze:Właśnie, zamiast gadać głupoty i chodzić po forach to byś się za workbook zabrał. Zrobię BeGiePa bez SDNów, opowiem o eMPeeLeSach i już będzie Twoja kolej - masz tylko dwa tygodnie :)
Teraz pora na głaskanie uprzejmościami. Zaprezentowałeś w odpowiedzi wysoki poziom merytoryczny, ale tylko do tej wąskiej części, która była Ci na rękę, a i nawet tam minąłeś się z przesłaniem. :)

lbromirs
CCIE
CCIE
Posty: 3936
Rejestracja: 30 lis 2006, 08:44

Re: Cisco Nexus 1000v vs VMware vDS

#3

#3 Post autor: lbromirs » 02 kwie 2017, 22:36

gangrena pisze:
lbromirs pisze:VMWare podjął decyzję o usunięciu API, co wg. gangreny jest oznaką większej otwartości. Koniec dyskusji :)
Jak już mamy się tak głaskać przeinaczaniami, to według lbromirs większa otwartość, to tylko w stronę Cisco. :D
Nic takiego nie napisałem :)
gangrena pisze:Programowalność nie równa się programowalności. Gratuluję Cisco QFP i X1, co nie zmienia trendu korzyści uruchamiania usług sieciowych na x86. TCAM jest hamulcowym.
O tym właśnie robiłem swoją ostatnią sesję na PLNOGu. Przecież.
gangrena pisze:Teraz pora na głaskanie uprzejmościami. Zaprezentowałeś w odpowiedzi wysoki poziom merytoryczny, ale tylko do tej wąskiej części, która była Ci na rękę, a i nawet tam minąłeś się z przesłaniem. :)
Nie.

(beat this!)

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2342
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: Cisco Nexus 1000v vs VMware vDS

#4

#4 Post autor: gangrena » 02 kwie 2017, 22:51

lbromirs pisze:Nic takiego nie napisałem :)
Użyłem Twojego podejścia do śmieszkowania i w kolejnej wypowiedzi od razu mnie zrozumiałeś. Ja też nic takiego nie napisałem, co twierdzisz, że twierdzę. :)
lbromirs pisze:O tym właśnie robiłem swoją ostatnią sesję na PLNOGu. Przecież.
Super, gratuluję sesji. Pytanie, jakie jest Twoje przesłanie? Z którym punktem mojej wypowiedzi się nie zgadzasz, zgadzasz lub co chcesz mi przekazać? Wbiłeś się w dyskusję z tyradą o ASICach przeczącą temu, że P4 z Barefoot jest ok, ale która w zasadzie potwierdza to, o czym mówiłem, czyli "Nie wykluczam oczywiście, że trend się odwróci na bazie nowego podzespołu."
lbromirs pisze:Nie.

(beat this!)
O ACI porozmawiam sobie z kompetentnymi osobami np. z xalem lub konradrz. :P

(how about this?)

lbromirs
CCIE
CCIE
Posty: 3936
Rejestracja: 30 lis 2006, 08:44

Re: Cisco Nexus 1000v vs VMware vDS

#5

#5 Post autor: lbromirs » 02 kwie 2017, 23:43

gangrena pisze:
lbromirs pisze:Nic takiego nie napisałem :)
Użyłem Twojego podejścia do śmieszkowania i w kolejnej wypowiedzi od razu mnie zrozumiałeś. Ja też nic takiego nie napisałem, co twierdzisz, że twierdzę. :)
Cytat z Twojej wypowiedzi: "Mówienie, że VMware się zamyka nie jest zgodne z prawdą."
Cytat z ogłoszenia VMWare (podlinkowane jako screenshot ale źródło jest tutaj: "VMware is announcing discontinuation of its third party virtual switch (vSwitch) program, and plans to deprecate the VMware vSphere APIs used by third party switches in the release following vSphere 6.5 Update 1. Subsequent vSphere versions will have the third party vSwitch APIs completely removed and third party vSwitches will no longer work."

No więc jednak to, że VMWare sobie dłubie z OVSem i wspomnianym przez Ciebie NSX-T to jedno (pominę milczeniem...), a to, że VMWare jednak odcina się od 3rd party switches to drugie.
gangrena pisze:Pytanie, jakie jest Twoje przesłanie? Z którym punktem mojej wypowiedzi się nie zgadzasz, zgadzasz lub co chcesz mi przekazać? Wbiłeś się w dyskusję z tyradą o ASICach przeczącą temu, że P4 z Barefoot jest ok, ale która w zasadzie potwierdza to, o czym mówiłem, czyli "Nie wykluczam oczywiście, że trend się odwróci na bazie nowego podzespołu."
Zwróciłem w ten sposób uwagę, że po pierwsze trend jest "od zawsze" (w sieciowej perspektywie ostatnie 17 lat to w zasadzie 'zawsze') - sieci są programowalne dzięki ASICom z funkcjami reprogramowania (de facto mariaży NPU z ASICiem) i nic wielkiego się tu nie zmieni. Kolejne funkcje będą migrowały z aplikacji do sieci/krzemu, a przyśpieszyć ten trend może tylko prawdziwie otwarty ASIC a nie kolejna firma, która próbując mydlić oczy open source'm (P4), popycha swoje zamknięte ASICi (cytując za ich własną stroną: "Not only did Barefoot create the first programmable switch silicon that performs at better than ASIC speeds, we also made programming it easy and openly available.".

"Better than ASIC speeds". Tak. Dokładnie tak jak 3COM w którymś momencie postanowił mnożyć przepustowość portu Ethernet razy dwa, bo full duplex już nie było wystarczające ;)

A w swojej sesji mówiłem o tym, że teraz szybko i wygodnie prototypuje się w x86 i wiele rzeczy już tam zostaje, ale część funkcjonalności w naturalny sposób spływa na NPU nowych generacji i programowalne ASICi. Wymieniłem swoją drogą zarówno P4 jako jeden z kamili milowych na drodze do realnego rozpowszechniania się SDNów (choć to nadal duży znak zapytania, ale krok do przodu został zrobiony), jak i Martina Casado, twórcę NSXa, który VMWare już opuścił, ale zanim NSXa stworzył, rozpoczął projekt Ethane.

Nie same fakty "że tak się robi" są ważne, bo to się dzieje i działo przez dekady. Raczej przyśpieszenie trendu produkcji nowych rzeczy nie dotykających sprzętu w ogóle, tak jak wspomniane sieci nakładkowe. Nakładki stały się wygodne, bo infrastruktura nie dawała się łatwo programować a dzięki tunelowi A<>B dało się do pewnego stopnia ominąć sieciowców i cała resztę aplikacji wyklikać sobie w GUI. Zwróciłbym raczej uwagę na to, że wokół tworzenia i wdrażania na szerszą skalę prawdziwie nowych, interesujących mechanizmów sieciowych (takich jak choćby ALTO, SAF wbudowany do EIGRP czy w końcu NDN/CCN) w zasadzie niewiele się dzieje. Cały czas zajmujemy się budowaniem kolejnej warstwy abstrakcji a fundamentalnie nic się nie zmienia od czasu ustalenia, że mamy adres A, adres B i trzeba zrobić routing. Kręcenie się w kółko jest męczące.
gangrena pisze:
lbromirs pisze:Nie.

(beat this!)
O ACI porozmawiam sobie z kompetentnymi osobami np. z xalem lub konradrz. :P

(how about this?)
Ough. Zabolało. Śmieszki mi pouciekały.

Normalnie.

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2342
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: Cisco Nexus 1000v vs VMware vDS

#6

#6 Post autor: gangrena » 03 kwie 2017, 00:31

lbromirs pisze:Cytat z Twojej wypowiedzi: "Mówienie, że VMware się zamyka nie jest zgodne z prawdą."

No więc jednak to, że VMWare sobie dłubie z OVSem i wspomnianym przez Ciebie NSX-T to jedno (pominę milczeniem...), a to, że VMWare jednak odcina się od 3rd party switches to drugie.
Moja wypowiedź dotyczy całościowego spojrzenia na VMware. Coś zamyka, gdzie indziej otwiera. Przykłady wymieniłem i nie ograniczają się one tylko do OVS, czy NSX-T z KVM. Selektywnie jest zamknięcie API, ogólnie jest dużo więcej inicjatyw. Wypowiedź śmieszkująca w stylu odwrócenia kota ogonem "VMWare podjął decyzję o usunięciu API, co wg. gangreny jest oznaką większej otwartości", to już chęć ukrócenia dyskusji poprzez ironię.
lbromirs pisze:Zwróciłem w ten sposób uwagę, że po pierwsze trend jest "od zawsze" (w sieciowej perspektywie ostatnie 17 lat to w zasadzie 'zawsze') - sieci są programowalne dzięki ASICom z funkcjami reprogramowania (de facto mariaży NPU z ASICiem) i nic wielkiego się tu nie zmieni. Kolejne funkcje będą migrowały z aplikacji do sieci/krzemu, a przyśpieszyć ten trend może tylko prawdziwie otwarty ASIC a nie kolejna firma, która próbując mydlić oczy open source'm (P4), popycha swoje zamknięte ASICi (cytując za ich własną stroną: "Not only did Barefoot create the first programmable switch silicon that performs at better than ASIC speeds, we also made programming it easy and openly available.".
Programowalność taka, czy inna jest od zawsze, ale trend przejścia funkcjonalności z ASIC/TCAM już nie. Pokazały to architektury routerów, pokazuje to cała branża sieciowa włączając akronimy NFV, VNF, SDN, itp. Trendu nie musi odwrócić P4. Może to być coś innego.
lbromirs pisze:"Better than ASIC speeds". Tak. Dokładnie tak jak 3COM w którymś momencie postanowił mnożyć przepustowość portu Ethernet razy dwa, bo full duplex już nie było wystarczające ;)

A w swojej sesji mówiłem o tym, że teraz szybko i wygodnie prototypuje się w x86 i wiele rzeczy już tam zostaje, ale część funkcjonalności w naturalny sposób spływa na NPU nowych generacji i programowalne ASICi. Wymieniłem swoją drogą zarówno P4 jako jeden z kamili milowych na drodze do realnego rozpowszechniania się SDNów (choć to nadal duży znak zapytania, ale krok do przodu został zrobiony), jak i Martina Casado, twórcę NSXa, który VMWare już opuścił, ale zanim NSXa stworzył, rozpoczął projekt Ethane.
Ok, czyli się zgadzamy z małą adnotacją, że część oprogramowania routerów wpierw była dostępna na NPU, a dopiero potem na x86.
Zaś link o Martinie Cassado tak bardzo jest istotny w dyskusji, jak link o Mario Prem Luca i Soni (twórcach ACI), którzy opuścili Cisco.
lbromirs pisze:Nie same fakty "że tak się robi" są ważne, bo to się dzieje i działo przez dekady. Raczej przyśpieszenie trendu produkcji nowych rzeczy nie dotykających sprzętu w ogóle, tak jak wspomniane sieci nakładkowe. Nakładki stały się wygodne, bo infrastruktura nie dawała się łatwo programować a dzięki tunelowi A<>B dało się do pewnego stopnia ominąć sieciowców i cała resztę aplikacji wyklikać sobie w GUI.
Sieci nakładkowe mogą, ale zazwyczaj nie pomijają sieciowców, gdyż oni je przygotowują i nimi zarządzają.
lbromirs pisze:Zwróciłbym raczej uwagę na to, że wokół tworzenia i wdrażania na szerszą skalę prawdziwie nowych, interesujących mechanizmów sieciowych (takich jak choćby ALTO, SAF wbudowany do EIGRP czy w końcu NDN/CCN) w zasadzie niewiele się dzieje. Cały czas zajmujemy się budowaniem kolejnej warstwy abstrakcji a fundamentalnie nic się nie zmienia od czasu ustalenia, że mamy adres A, adres B i trzeba zrobić routing. Kręcenie się w kółko jest męczące.
Bym powiedział, że budowanie nowych funkcjonalności w oparciu o routing (włączając to, co podałeś) niewiele zmienia. Zmiana jest na poziomie aplikacji i oferowanych usług. Infrastruktura podlega kolejnym etapom konwergencji, uwspólnienia mianownika i to wpływa na zastosowany model sieciowy. Jako przykład, kiedyś rozmawialiśmy, że długoterminowo dążymy do modelu L3. Model ten będzie wypracowywany w warstwie aplikacji, nie poprzez nowe, wymyślne mechanizmy ALTO, SAF itd.

lbromirs
CCIE
CCIE
Posty: 3936
Rejestracja: 30 lis 2006, 08:44

Re: Cisco Nexus 1000v vs VMware vDS

#7

#7 Post autor: lbromirs » 03 kwie 2017, 10:23

gangrena pisze:
lbromirs pisze:Cytat z Twojej wypowiedzi: "Mówienie, że VMware się zamyka nie jest zgodne z prawdą."

No więc jednak to, że VMWare sobie dłubie z OVSem i wspomnianym przez Ciebie NSX-T to jedno (pominę milczeniem...), a to, że VMWare jednak odcina się od 3rd party switches to drugie.
Moja wypowiedź dotyczy całościowego spojrzenia na VMware. Coś zamyka, gdzie indziej otwiera.
No tak, oczywiście. Przecież nic nie jest ani tylko czarne ani białe.
gangrena pisze:Przykłady wymieniłem i nie ograniczają się one tylko do OVS, czy NSX-T z KVM. Selektywnie jest zamknięcie API, ogólnie jest dużo więcej inicjatyw. Wypowiedź śmieszkująca w stylu odwrócenia kota ogonem "VMWare podjął decyzję o usunięciu API, co wg. gangreny jest oznaką większej otwartości", to już chęć ukrócenia dyskusji poprzez ironię.
Zwracam Ci tylko uwagę, że od tego zaczął się refresh dyskusji.
gangrena pisze:Ok, czyli się zgadzamy z małą adnotacją, że część oprogramowania routerów wpierw była dostępna na NPU, a dopiero potem na x86.
Zaś link o Martinie Cassado tak bardzo jest istotny w dyskusji, jak link o Mario Prem Luca i Soni (twórcach ACI), którzy opuścili Cisco.
Wspomniałem o Martinie ponieważ stworzył Ethane i można traktować to jako początek rozmów o przenoszeniu elastyczniej usług na x86. Wspominanie o MPLSie jest w tej sytuacji z Twojej strony lekkim jednak nadużyciem - i śmiem twierdzić, że to właśnie ten przytyk nie jest istotny w dyskusji.
gangrena pisze:
lbromirs pisze:Zwróciłbym raczej uwagę na to, że wokół tworzenia i wdrażania na szerszą skalę prawdziwie nowych, interesujących mechanizmów sieciowych (takich jak choćby ALTO, SAF wbudowany do EIGRP czy w końcu NDN/CCN) w zasadzie niewiele się dzieje. Cały czas zajmujemy się budowaniem kolejnej warstwy abstrakcji a fundamentalnie nic się nie zmienia od czasu ustalenia, że mamy adres A, adres B i trzeba zrobić routing. Kręcenie się w kółko jest męczące.
Bym powiedział, że budowanie nowych funkcjonalności w oparciu o routing (włączając to, co podałeś) niewiele zmienia. Zmiana jest na poziomie aplikacji i oferowanych usług. Infrastruktura podlega kolejnym etapom konwergencji, uwspólnienia mianownika i to wpływa na zastosowany model sieciowy. Jako przykład, kiedyś rozmawialiśmy, że długoterminowo dążymy do modelu L3. Model ten będzie wypracowywany w warstwie aplikacji, nie poprzez nowe, wymyślne mechanizmy ALTO, SAF itd.
Tak jest, ale niestety aplikacje poza uelastycznieniem (dzięki przesunięciu się do komunikacji w L3 i modelu mikrousługowego) nic nowego nie wnoszą - i to już od paru lat. Mydlenie oczu w postaci sieci nakładkowych (w kontekście dyskusji o powstawaniu nowych mechanizmów i funkcjonalności) nie rozwiązuje tutaj żadnych problemów, choć jest sprzedawane (nie twierdzę, że przez Ciebie) jako remedium na wszystkie problemy.

Trochę żal, bo nadal wiele projektów nie zostało zrealizowanych. Ale to szansa dla programistów sieciowych, którzy chcą zaatakować programowalne sieci :)

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2342
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: Cisco Nexus 1000v vs VMware vDS

#8

#8 Post autor: gangrena » 03 kwie 2017, 12:45

lbromirs pisze:No tak, oczywiście. Przecież nic nie jest ani tylko czarne ani białe.
Nieprawdziwe parafrazy, które tworzysz przeczą Twojemu "oczywiście".
lbromirs pisze:Zwracam Ci tylko uwagę, że od tego zaczął się refresh dyskusji.
To zwróć uwagę na całość wypowiedzi.
lbromirs pisze:Wspomniałem o Martinie ponieważ stworzył Ethane i można traktować to jako początek rozmów o przenoszeniu elastyczniej usług na x86. Wspominanie o MPLSie jest w tej sytuacji z Twojej strony lekkim jednak nadużyciem - i śmiem twierdzić, że to właśnie ten przytyk nie jest istotny w dyskusji.
Łukasz, zaczynasz sobie żartować z czytania ze zrozumieniem. Wspomniałeś w linku o odejściu Martina Casado. Napisałem, że to wnosi tyle do dyskusji co info o odejściu MPLS z Cisco. Tymczasem teraz mówisz, że wspomniałeś o Martinie z powodu Ethane. Super, ale to nie o tym była ta uwaga, lecz o linku i info o odejściu Casado.
lbromirs pisze:Tak jest, ale niestety aplikacje poza uelastycznieniem (dzięki przesunięciu się do komunikacji w L3 i modelu mikrousługowego) nic nowego nie wnoszą - i to już od paru lat. Mydlenie oczu w postaci sieci nakładkowych (w kontekście dyskusji o powstawaniu nowych mechanizmów i funkcjonalności) nie rozwiązuje tutaj żadnych problemów, choć jest sprzedawane (nie twierdzę, że przez Ciebie) jako remedium na wszystkie problemy.
Nie zgodzę, co do zdania o aplikacjach, co pokazują nowe aplikacje nie wymagające dotychczasowego modelu infrastruktury.

Co do zdania o sieciach nakładkowych, to jest to kolejny etap w ewolucji, który pomaga przenieść L2 oraz uprościć architekturę. Wiesz o tym bardzo dobrze. Polecam porównanie na podstawie sesji z PLNOG17: https://www.youtube.com/watch?v=2vvlPtgUBHg&t

VMware NSX więcej mówi o bezpieczeństwie, niż o sieciach nakładkowych. Sieci nakładkowe nie są niezbędne. :)
lbromirs pisze:Trochę żal, bo nadal wiele projektów nie zostało zrealizowanych. Ale to szansa dla programistów sieciowych, którzy chcą zaatakować programowalne sieci :)
Tak.

lbromirs
CCIE
CCIE
Posty: 3936
Rejestracja: 30 lis 2006, 08:44

Re: Cisco Nexus 1000v vs VMware vDS

#9

#9 Post autor: lbromirs » 03 kwie 2017, 18:47

gangrena pisze:
lbromirs pisze:No tak, oczywiście. Przecież nic nie jest ani tylko czarne ani białe.
Nieprawdziwe parafrazy, które tworzysz przeczą Twojemu "oczywiście".
Użyłem ironii, jeśli nie zauważyłeś. Przepraszam.
gangrena pisze:
lbromirs pisze:Zwracam Ci tylko uwagę, że od tego zaczął się refresh dyskusji.
To zwróć uwagę na całość wypowiedzi.
Całość wypowiedzi składa się z wielu wątków.
gangrena pisze:
lbromirs pisze:Wspomniałem o Martinie ponieważ stworzył Ethane i można traktować to jako początek rozmów o przenoszeniu elastyczniej usług na x86. Wspominanie o MPLSie jest w tej sytuacji z Twojej strony lekkim jednak nadużyciem - i śmiem twierdzić, że to właśnie ten przytyk nie jest istotny w dyskusji.
Łukasz, zaczynasz sobie żartować z czytania ze zrozumieniem. Wspomniałeś w linku o odejściu Martina Casado. Napisałem, że to wnosi tyle do dyskusji co info o odejściu MPLS z Cisco. Tymczasem teraz mówisz, że wspomniałeś o Martinie z powodu Ethane. Super, ale to nie o tym była ta uwaga, lecz o linku i info o odejściu Casado.
Napisałem, cytuje: "jak i Martina Casado, twórcę NSXa, który VMWare już opuścił, ale zanim NSXa stworzył, rozpoczął projekt Ethane.".

To jednak była uwaga o stworzeniu Ethane, a wtrącenie o opuszczeniu VMWare było jedynie wtrąceniem.
gangrena pisze:
lbromirs pisze:Tak jest, ale niestety aplikacje poza uelastycznieniem (dzięki przesunięciu się do komunikacji w L3 i modelu mikrousługowego) nic nowego nie wnoszą - i to już od paru lat. Mydlenie oczu w postaci sieci nakładkowych (w kontekście dyskusji o powstawaniu nowych mechanizmów i funkcjonalności) nie rozwiązuje tutaj żadnych problemów, choć jest sprzedawane (nie twierdzę, że przez Ciebie) jako remedium na wszystkie problemy.
Nie zgodzę, co do zdania o aplikacjach, co pokazują nowe aplikacje nie wymagające dotychczasowego modelu infrastruktury.
Hm, a o czym konkretnie mówisz w tym momencie? Bo napisałem powyżej, że aplikacje "nie wnoszą nic nowego do mechanizmów komunikacji poza uelastycznieniem (dzięki przesunięciu się do komunikacji w L3 i modelu mikrousługowego)". Nie wykorzystują szeroko mechanizmów typu odkrywanie najbliższego źródła usługi korzystając z mechanizmów sieciowych (na przykład), ale raczej wydłubują to w samych sobie. Vide np. HTTP, w które wbudowany jest już teraz nie jeden a parę języków przenoszenia treści i jej sygnalizacji. Zamiast skorzystać z protokołów warstw niższych i odciążyć warstwę aplikacji.
gangrena pisze:Co do zdania o sieciach nakładkowych, to jest to kolejny etap w ewolucji, który pomaga przenieść L2 oraz uprościć architekturę. Wiesz o tym bardzo dobrze. Polecam porównanie na podstawie sesji z PLNOG17: https://www.youtube.com/watch?v=2vvlPtgUBHg&t
Tak, zgadzam się z Tobą, lecz nie na to zwracam uwagę. Raczej na to, że zamiast zastanawiać się/standaryzować nowe mechanizmy w warstwie sieciowej i zdejmować obciążenie z aplikacji, pod szyldem 'zrobimy to overlayem' sprzedaje się remedium na: odległość, opóźnienie, QoS, problemy z routingiem, load-balancing i mobilność w L2. Hype SDNowy (w mojej ocenie) zastąpiony został hype'm overlayowym.
gangrena pisze:
lbromirs pisze:Trochę żal, bo nadal wiele projektów nie zostało zrealizowanych. Ale to szansa dla programistów sieciowych, którzy chcą zaatakować programowalne sieci :)
Tak.
Tak właśnie otóż.

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2342
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: Cisco Nexus 1000v vs VMware vDS

#10

#10 Post autor: gangrena » 03 kwie 2017, 22:11

lbromirs pisze:Hm, a o czym konkretnie mówisz w tym momencie? Bo napisałem powyżej, że aplikacje "nie wnoszą nic nowego do mechanizmów komunikacji poza uelastycznieniem (dzięki przesunięciu się do komunikacji w L3 i modelu mikrousługowego)". Nie wykorzystują szeroko mechanizmów typu odkrywanie najbliższego źródła usługi korzystając z mechanizmów sieciowych (na przykład), ale raczej wydłubują to w samych sobie. Vide np. HTTP, w które wbudowany jest już teraz nie jeden a parę języków przenoszenia treści i jej sygnalizacji. Zamiast skorzystać z protokołów warstw niższych i odciążyć warstwę aplikacji.
Chodzi mi o "nie wnoszą nic nowego do mechanizmów komunikacji poza uelastycznieniem". Moim zdaniem wnoszą więcej zmian, czy też nowego/innego podejścia do zastosowanego modelu routingu, infrastruktury, usług sieciowych, niż oddolne inicjatywy dotyczące protokołów jak ALTO, SAF, itd.
lbromirs pisze:Tak, zgadzam się z Tobą, lecz nie na to zwracam uwagę. Raczej na to, że zamiast zastanawiać się/standaryzować nowe mechanizmy w warstwie sieciowej i zdejmować obciążenie z aplikacji, pod szyldem 'zrobimy to overlayem' sprzedaje się remedium na: odległość, opóźnienie, QoS, problemy z routingiem, load-balancing i mobilność w L2. Hype SDNowy (w mojej ocenie) zastąpiony został hype'm overlayowym.
Szczerze mówiąc nie widzę tego na rynku. Jeszcze nie spotkałem się osobą, która by mówiła, że remedium na odległość, opóźnienie, QoS jest overlay. Na problemy z routingiem, to zależy. Natomiast na load-balancing i mobilność już chociażby LISP, który korzysta z overlaya, mówił, że jest dobrym remedium. Hype SDN-owy został raczej zastąpiony hype-em chmurowym.

lbromirs
CCIE
CCIE
Posty: 3936
Rejestracja: 30 lis 2006, 08:44

Re: Cisco Nexus 1000v vs VMware vDS

#11

#11 Post autor: lbromirs » 03 kwie 2017, 22:19

gangrena pisze:
lbromirs pisze:Hm, a o czym konkretnie mówisz w tym momencie? Bo napisałem powyżej, że aplikacje "nie wnoszą nic nowego do mechanizmów komunikacji poza uelastycznieniem (dzięki przesunięciu się do komunikacji w L3 i modelu mikrousługowego)". Nie wykorzystują szeroko mechanizmów typu odkrywanie najbliższego źródła usługi korzystając z mechanizmów sieciowych (na przykład), ale raczej wydłubują to w samych sobie. Vide np. HTTP, w które wbudowany jest już teraz nie jeden a parę języków przenoszenia treści i jej sygnalizacji. Zamiast skorzystać z protokołów warstw niższych i odciążyć warstwę aplikacji.
Chodzi mi o "nie wnoszą nic nowego do mechanizmów komunikacji poza uelastycznieniem". Moim zdaniem wnoszą więcej zmian, czy też nowego/innego podejścia do zastosowanego modelu routingu, infrastruktury, usług sieciowych, niż oddolne inicjatywy dotyczące protokołów jak ALTO, SAF, itd.
A możesz podać jakiś przykład takiej aplikacji która wnosi coś nowego? Open/R? Ale to po prostu nowy protokół routingu, tyle, że prawie "w warstwie aplikacji".

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2342
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: Cisco Nexus 1000v vs VMware vDS

#12

#12 Post autor: gangrena » 03 kwie 2017, 22:56

lbromirs pisze:A możesz podać jakiś przykład takiej aplikacji która wnosi coś nowego? Open/R? Ale to po prostu nowy protokół routingu, tyle, że prawie "w warstwie aplikacji".
Choćby aplikacje bezstanowe. Wnoszą coś nowego poza elastycznością, a mianowicie upraszczają architekturę bezpieczeństwa, tj. nie trzeba np. rozciągać klastra firewalli na kilka lokalizacji dla sesji tranzakcyjnych. Tranzakcje trzymane są na poziomie storage, nie na poziomie aplikacji. Upraszcza się również routing/load-balancing. Można łatwiej wykorzystać anycast. Łatwiej zapewnić wysoką dostępność.

lbromirs
CCIE
CCIE
Posty: 3936
Rejestracja: 30 lis 2006, 08:44

Re: Cisco Nexus 1000v vs VMware vDS

#13

#13 Post autor: lbromirs » 03 kwie 2017, 23:58

gangrena pisze:
lbromirs pisze:A możesz podać jakiś przykład takiej aplikacji która wnosi coś nowego? Open/R? Ale to po prostu nowy protokół routingu, tyle, że prawie "w warstwie aplikacji".
Choćby aplikacje bezstanowe. Wnoszą coś nowego poza elastycznością, a mianowicie upraszczają architekturę bezpieczeństwa, tj. nie trzeba np. rozciągać klastra firewalli na kilka lokalizacji dla sesji tranzakcyjnych. Tranzakcje trzymane są na poziomie storage, nie na poziomie aplikacji. Upraszcza się również routing/load-balancing. Można łatwiej wykorzystać anycast. Łatwiej zapewnić wysoką dostępność.
Dobry przykład, dzięki.

BTW, ile razy jeszcze zmienisz tytuł wątku z takiego, który nie zwraca uwagi na VMWare vSwitch i zlikwidowanie API dla przełączników wirtualnych innych firm? ;) Może zostawmy wątek o tytule jak był a całą dyskusję od momentu skręcenia w stronę aplikacji przeniesiemy do nowego?

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2342
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: Cisco Nexus 1000v vs VMware vDS

#14

#14 Post autor: gangrena » 04 kwie 2017, 01:08

lbromirs pisze:BTW, ile razy jeszcze zmienisz tytuł wątku z takiego, który nie zwraca uwagi na VMWare vSwitch i zlikwidowanie API dla przełączników wirtualnych innych firm? ;) Może zostawmy wątek o tytule jak był a całą dyskusję od momentu skręcenia w stronę aplikacji przeniesiemy do nowego?
Que? Przecież tytuł wątku o VMware pozostał w oryginale jako osobny temat. Wydzieliłem tylko posty od początku Twojej wielowątkowej dygresji, która na początku miała zabić dyskusję niby bardzo zabawną ironią, a potem przekształciła się w niby konstruktywną rozmowę, która wybiegła w pole. Tak jak Twoje pierwsze, tak i ostatnie zdanie znowu świadczy, że dobrze zrobiłem. EOT, chyba, że masz coś konstruktywnego do powiedzenia na temat otwartości VMware, API, ACI. To zapraszam do pierwotnego wątku.

ODPOWIEDZ