[Discuss] Babel im Mesh mit IPv6

[Sven-Ola Tuecke]

Adrian,

deine Analyse deckt sich ungefaehr mit dem, was ich im Laufe der Zeit gelernt 
habe. Allerdings kann man das Problem "Packetloss steigt bei 
Nutzdatenbelastung" mit dem Befehl "tc" entschaerfen. Die 1+1=2-Eigenschaft 
ist eine Naeherung, die fuer Empfang-Speichern-Weitersenden-Kommunikation 
ueber ein einzelnes Interface ganz gut passt. Aber leider einen Medienwechsel 
(oder "andere Leitung im Spiel", "Ethernet under Systembus dazwischen", "2. 
Wifikarte mit anderem Kanal", [...]) nicht beruecksichtigt. Letzteres waere 
ein Todo fuer Weiterentwicklungen...

Die Forderung nach einem updatebaren Testbett kenne ich bereits von der 
Diskussion bei der B.A.T.M.A.N-Einfuehrung. Gleiches galt + gilt fuer Updates 
z.B. des olsrd. Im Prinzip klappt es ganz gut, wenn man 2 getrennte 
IP-Bereiche fuer unterschiedliche Routingprotokolle verwendet. Dann bleibt 
nur noch die Verwaltung bzw. die Zuteilung von nicht-teilbaren Ressourcen, 
wie die Default-Route oder das (DHCP+NAT)-Klienten-Zielnetz. Ich koennte mir 
vorstellen, einen automatischen Lade+Ausfuehrmechanismus fuer 
Testinstallationen zu machen. Vorausgesetzt, der Eingang wird 
einigermaszen "bewacht" (Signatur einer Gruppe von Leuten die sich kuemmern) 
und eine "Auto-Bestrafung" (kill) bei Nutzung von singulaer vorhandenen 
Ressourcen (Non-Policy-Routes, falscher IP-Bereich, zuviel 
Mem,CPU,Bandbreite).

Im Uebrigen hat sich Juliusz offenbar was feines einfallen lassen, um das 
Problem der Topoinfo-Verbreitung bei unzuverlaessig arbeitendem 
Transportmedien zu loesen. Das klingt spannend und stand AFAIK u.a. bei 
Hannes auf einer der erweiterten Todo's fuer den olsrd++. Insofern waeren 
Praxis-Erfahrungen mit Juliusz Loesung sicher wertvoll. Ich vermute, dass 
dieses Problem nicht mit einer einzelnen guten Idee aus der Welt zu schaffen 
ist. Moeglicherweise muss man auch noch den Ursprung der Idee pruefen.

Achso: Ich darf daran erinnern, dass es ziemlich lange braucht um von einer 
Idee zu einem in der Praxis einsetzbaren "Produkt" zu gelangen. Da rechnet 
man besser in Mannjahren (+ nicht in Mann-Wochen). Von daher wuerd' ich Euch 
empfehlen, das laufende Kern-Netz nicht einfach mal so umzubauen...

// Sven-Ola

Am Sonntag 21 Dezember 2008 21:47:48 schrieb Adrian D:
> wir haben das selbe problem wie mit einem metrik-update bei olsr: wir
> brauchen einen testmöglichkeit bzw einen update-pfad für das netz.
> adhoc fallen mir zwei varianten ein: ein anderer ip range oder ein
> anderes vlan über funk. beides hat den nachteil es irgendwann mal eine
> big-bang-umstellung geben muss - aber vielleicht fällt uns noch was
> besseres ein? eines, wo wir routen über die jeweils andere metrik
> automatisch integrieren können? hmm..
> allzu lange werden wir uns davor nicht mehr drücken können.
>
>
> ich war leider nicht bei dem babel-vortrag dabei, hab jetzt nur die
> folien gesehen und muss sagen: super dass man sich wichtiger nachteile
> des olsr angenommen hat (zb synchronizität bei route veränderungen).
> aber ein zentraler nachteil bleibt: es verwendet ebenfalls die
> ETX-metrik mit den zwei gravierendsten nachteilen:
> *) es bewertet einen hop mit 50% packetloss (ETX=2) als besser, als zwei
> hops mit jeweils nur 1% packetloss (ETX 1.01+1.01=2.02)
> *) wird ein link tatsächlich belastet, konkurrieren datenpakete mit
> hellopaketen was den ETX wert ansteigen läßt, und zu route-switching auf
>  schlechtere routen führen kann. zumindest kommt es bei babel beim
> routswitching nicht zu einstweiligen schleifen und damit zu aussetzern.
>
> gibts irgendwo eine liste an verbesserungen die olsr v2 verspricht? das
> was ich als draft vom juli gesehen habe, verdient meiner ansicht nach
> nicht die version 2.0.
>
> adrian.