[Dump] parallelle meshes

[Harald Geyer]

> das ich ja auch ähnliches vorhab,.. (wir dann also schon bei 3 routing
> daemons pro Router wären)
> 
> (allerdings k.a. ob ich zuerst einen olsr-fork mit paar intressanten mods #
> mach, und dann erst mit parallel setup anfang oder umgekehrt)
> 
> und die ressourcen eines routers irgendwannmal zu neige gehen,..

Also was bei babel am meisten Ressourcen verbraucht ist eigentlich
das kmod-ipv6...

Allerdings ist babel in Hinsicht Parallelbetrieb ohne sich einzumischen
extrem dankbar: Es muss nichts außer den link local Adressen announcen
und man kann in der /etc/babel.conf genau spezifizieren
welche Routen es announcen soll und welche nicht. Damit kann man alle
Arten von Interferenzen recht gut in den Griff kriegen, braucht keine
eigenen Addressspaces etc...

Bei einem Shadow-OLSR-Netz hast du viel mehr Arbeit vor dir.
Und was Ressourcen betrifft, musst du dann noch irgendein Monitoringtool
auch mit einplanen, oder wie willst du an Daten kommen?
 
> könnt vertrauenfördernd sein, oder das gegnteil bewirken, doer aber auc
> h im
> endeffekt uns auch ärger machen,..

Letzteres am allermeisten.

> denn wer stellt dann die timeslots ein (ich würde das eher nicht dem
> node-owner (alleinig) in die hand geben wollen)

Nein, timeslots sind schlecht, weil viel zu fehleranfällig und die
Daten schwer auszuwerten. Und wenn du regelmäßig neue mods testen
willst, dann geht das ohne automatisches deploymentsystem sowieso
nicht - speziell wenn du immer wieder andere mods testen willst.

Bei einem automatischen System machen sicher eine Menge Leute nicht
mit (andere dafür umso mehr) - zum Beispiel auf meinen Knoten laufen
jetzt schon zu viele extras. Da kann nicht so einfach wer anderer
als ich darauf herumfuhrwerken... und schon gar kein Skript.

Allerdings das automatische Deploymentsystem könnte für babel auch
interessant werden - immerhin ist da noch immer jederzeit mit
inkompatiblen Protokolländerungen zu rechnen.

Also wenn du wirklich olsr-mods testen willst, dann stell' ich wohl
am besten die sit-tunnel auf gre um, wie von Juliusz
vorgeschlagen und dein erster mod ist, den olsrd gre tauglich zu
machen.

> ne andere frage, wie hast du vor babel im ipkg zu konfigurieren
> 
> auf allen interfaces, oder nur auf wan/funk, oder auf denen wo auch olsr
> läuft,..

Noch nicht ganz klar. Derzeit bin ich gerade dabei babel kennenzulernen,
wofür die 4-5 aktuell aktiven Nodes ausreichen.

Beim ipk hängt vieles davon ab, ob ich so viele airtunnel brauche, dass
ich die tunnel vom ipk machen lass' oder ob ich nur ein einfaches 
babel-ipk mach' und tunnel-knoten immer ein Spezialfall sind.

Für den Fall, dass ich die Tunnel manuell grabe, würd' ich  
als Interfaceliste im ipk einfach "eth1 vlan0 vlan1" nehmen.

Wenn ich viele Tunnel brauche, dann muss ich Interfaceliste und
Tunnelkonfig im nvram ablegen, weil sonst ist das nach jedem
update weg...

Deine Mods klingen interessant: Wie wär's du schreibst einfach
OLSRv3 d'rauf und lässt andere die Arbeit machen? SCRN
 
> #  zurzeit angedachte mods (und mit kaum rücksicht auf RFC kompatibilit
> ät
> (vorallem punkt D))
> 
> A: lq-metrik mit sehr wenigen werten,
> und adaptiver validity time  -> nur sehr wenige metrikänderungen und auch
> sehr wenige tcs
> -> wenig traffic, und darum kein fisheye mehr nötig
> B: evt. latenzmessungen der links, evt. unicast packetloss messungen
> C: evt. non-wlandriver based linkspeed messungen (keineswegs genau)
> und das eher nur bei links mit wenig packetloss
> denn ich will nicht das ein link mit nennswert (d.h unicat packetloss
> erwartbar) packetloss nen besserer metrik kriegen kann, als ein langsamer
> ohn packetloss
> D: gewisse zeitliche synchonisierung (d.h. neue metrikwerte (wenn sie nicht
> exrteme verschlechterungen sind)) werden announct, aber erst z.b. 10
> sekunden später (abhängig von meshgrösse und der dringlichkeit)  (ü
> berall
> möglichst gleichzeitg) umgesetzt wird,..
> d.h. ziel ist jedenfalls deutlich gleichzeitiger als jetzt
> vermutlich werd ichs aber doch nicht probieren das ganze mesh zu
> synchronisieren (-;
> sondern einfach in den oslr paketen mit nem zusätzlichen timetovalidity
> (ttv) feld, immer abziehen wie lange das paket warten musste (und auch die
> bekannte durchschnitts-latenz des incoming links) (da ich fisheye eh auch
> weglassen will, ersetzte ich evt ttl durch ttv, allerdings bezweifle ich ob
> ich mit 8bit auskomm)
> E: sofortiges weitersenden von katastrophen-tcs (d.h. kein zamsammeln von
> messages auf ein grosses paket) und tcs mit niedriger ttv
> d.h. wenn einer seiner links plötzlich irre schlecht wird schickt der ols
> r
> tcs mit niedriger ttv, und erwartet das schnellstmöglich jeder davon
> erfährt,..
> gleichzeitg werd ich irgendwas einbauen müssen, dass evt. auf jeden knote
> n
> ein ratelimit (pro orinigator) gibt wieoft er solche tcs schicken darf und
> diese auch wirkich sofort weitergeleitet werden,..