CCIE.pl

site 4 CCIE wannabies
Dzisiaj jest 18 sty 2018, 20:29

Strefa czasowa UTC+01:00




Nowy temat  Odpowiedz w temacie  [ Posty: 14 ] 
Autor Wiadomość
Post #1 : 02 kwie 2017, 21:00 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3891
Cytuj:
Cytuj:
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 :)
Cytuj:
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 :)
Cytuj:
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


Na górę
Post #2 : 02 kwie 2017, 22:24 
Offline
CCIE/CCDE
CCIE/CCDE
Awatar użytkownika

Rejestracja: 08 mar 2004, 12:17
Posty: 2327
Lokalizacja: Wawa
Cytuj:
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
Cytuj:
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.
Cytuj:
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. :)


Na górę
Post #3 : 02 kwie 2017, 22:36 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3891
Cytuj:
Cytuj:
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 :)
Cytuj:
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ż.
Cytuj:
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!)


Na górę
Post #4 : 02 kwie 2017, 22:51 
Offline
CCIE/CCDE
CCIE/CCDE
Awatar użytkownika

Rejestracja: 08 mar 2004, 12:17
Posty: 2327
Lokalizacja: Wawa
Cytuj:
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ę. :)
Cytuj:
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."
Cytuj:
Nie.

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

(how about this?)


Na górę
Post #5 : 02 kwie 2017, 23:43 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3891
Cytuj:
Cytuj:
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.
Cytuj:
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.
Cytuj:
Cytuj:
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.


Na górę
Post #6 : 03 kwie 2017, 00:31 
Offline
CCIE/CCDE
CCIE/CCDE
Awatar użytkownika

Rejestracja: 08 mar 2004, 12:17
Posty: 2327
Lokalizacja: Wawa
Cytuj:
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ę.
Cytuj:
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.
Cytuj:
"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.
Cytuj:
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ą.
Cytuj:
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.


Na górę
Post #7 : 03 kwie 2017, 10:23 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3891
Cytuj:
Cytuj:
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.
Cytuj:
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.
Cytuj:
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.
Cytuj:
Cytuj:
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 :)


Na górę
Post #8 : 03 kwie 2017, 12:45 
Offline
CCIE/CCDE
CCIE/CCDE
Awatar użytkownika

Rejestracja: 08 mar 2004, 12:17
Posty: 2327
Lokalizacja: Wawa
Cytuj:
No tak, oczywiście. Przecież nic nie jest ani tylko czarne ani białe.
Nieprawdziwe parafrazy, które tworzysz przeczą Twojemu "oczywiście".
Cytuj:
Zwracam Ci tylko uwagę, że od tego zaczął się refresh dyskusji.
To zwróć uwagę na całość wypowiedzi.
Cytuj:
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.
Cytuj:
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. :)
Cytuj:
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.


Na górę
Post #9 : 03 kwie 2017, 18:47 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3891
Cytuj:
Cytuj:
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.
Cytuj:
Cytuj:
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.
Cytuj:
Cytuj:
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.
Cytuj:
Cytuj:
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.
Cytuj:
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.
Cytuj:
Cytuj:
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óż.


Na górę
Post #10 : 03 kwie 2017, 22:11 
Offline
CCIE/CCDE
CCIE/CCDE
Awatar użytkownika

Rejestracja: 08 mar 2004, 12:17
Posty: 2327
Lokalizacja: Wawa
Cytuj:
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.
Cytuj:
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.


Na górę
Post #11 : 03 kwie 2017, 22:19 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3891
Cytuj:
Cytuj:
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".


Na górę
Post #12 : 03 kwie 2017, 22:56 
Offline
CCIE/CCDE
CCIE/CCDE
Awatar użytkownika

Rejestracja: 08 mar 2004, 12:17
Posty: 2327
Lokalizacja: Wawa
Cytuj:
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ść.


Na górę
Post #13 : 03 kwie 2017, 23:58 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3891
Cytuj:
Cytuj:
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?


Na górę
Post #14 : 04 kwie 2017, 01:08 
Offline
CCIE/CCDE
CCIE/CCDE
Awatar użytkownika

Rejestracja: 08 mar 2004, 12:17
Posty: 2327
Lokalizacja: Wawa
Cytuj:
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.


Na górę
Wyświetl posty nie starsze niż:  Sortuj wg  
Nowy temat  Odpowiedz w temacie  [ Posty: 14 ] 

Strefa czasowa UTC+01:00


Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
cron
This Website is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco, Cisco Systems, CCDA, CCNA, CCDP, CCNP, CCIE, CCSI, CCIP, the Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. Używamy informacji zapisanych za pomocą cookies i podobnych technologii m.in. w celach reklamowych i statystycznych oraz w celu dostosowania naszych serwisów do indywidualnych potrzeb użytkowników. Mogą też stosować je współpracujące z nami firmy. W programie służącym do obsługi internetu można zmienić ustawienia dotyczące cookies. Korzystanie z naszych serwisów internetowych bez zmiany ustawień dotyczących cookies oznacza, że będą one zapisane w pamięci urządzenia.



Technologię dostarcza phpBB® Forum Software © phpBB Limited
Polski pakiet językowy dostarcza phpBB.pl