Connecting L2 clouds with a L3 protocol¶

Regarding this issue, there seem to be two approaches, one "scaling up" from L2 and another "scalilng down" from L3.

The goal (if possible) would be to design a network model where L2 clouds can be connected among them in an optimal way by exchanging some information from L2 and L3 and performing decisions based on this "shared view". The L2 clouds could be village-size or building-size, depending on the scenario, but the model should work for all cases.

Scaling up from L2 to L3:¶

Currently batman-adv has no way of announcing gateways to different networks appart from the default gateways (to the Internet). The developers are currently working on a design proposed at the Battlemesh v6 which consists of:
1) Use L2 and L3 anycast so that each gateway to the same network share MAC address and IP and then the hosts trying to access that network would choose the best (TQ) path. Every border node would be using batman gw_mode master, so clients would have the nearest border as default gw. (this will break the roaming(just in the case of natted internet))
2) Border nodes would announce through DHCP not only the default route but also the rest of the routes accesible through other borders. Connecting hosts in the same cloud would then have routes to every other cloud (and the Internet).
3) If routes announcement to hosts fails (broken clients, almost all :P ), they will still receive ICMP redirects when first trying to access another network. If this is also broken (which seems to be the case in Windows), then... ?

In this scenario, when a client wants to access the same cloud no L3 routing will be involved.
Antonio from batman-adv is currently working on this approach:
http://www.open-mesh.org/projects/open-mesh/wiki/Connecting-Batman-adv-clouds

( This approach seems to mix L2 and L3 a lot, usually the result of doing such a thing is something horrible "Porcata" --chanchada :P )
4) in antonio's proposal, the border gateways know the "cost" of reaching a destination network, so the clients will not really choose just the best (TQ) gateway to the destination, but the best exit considering the full path cost.

What Antonio is trying to do is not rely on the L3 protocol on top to get a meaningful metric for the full path. I guess we could solve this without adding batman-adv in the intermediate links (as his graphics show), by getting both protocols to "collaborate" sharing metrics.

Scaling "down" from L3 to L2:¶

p4u made these graphics:
http://dev.libre-mesh.org/attachments/download/2/smartmeshdraft.png

we still need a text description of the idea so we can share it and comment on.