[Interop-dev] CNML/Database Brainstorming: Help!
Dennis Bartsch
(spam-protected)
Sun May 13 23:44:04 CEST 2012
Hello,
> From: (spam-protected)
> On 05/11/12 18:16, Federico Capoano wrote:
> > *Routing protocol*
> > a device might have more than one routing protocol, think a case in
> > which a node functions as a bridge between 2 networks with different
> > routing protocols.
> > The routing protocol could be installed on a server or an access point,
> > or any other machine that has enough resources to run it, that's why I
> > advice to have a single table for devices.
> > In my opinion routing protocols should be related to the device table
> > and it should be possible to assign more than one to a single device.
> >
>
> maybe you some devices like hotspot doesn't have that so i think this
> should be out of the core too
I absolutely don't think that the routing protocol is an attribute of the node but
of every single link/neighbour a node has. In the PBerg firmware the default
configuration of simultaneous IPv4 an v6 OLSRd routing is to have 2 instances
of it running. But to improve the routing in favor of wired links and well built
backbone links another metric module is used (etx-ffeth instead of etx-ff). That
configuration is standard now in the (very) old FFF and recent backfire firmwares.
But because many nodes aren't running this 4and6 configuration yet, there are
2 maybe completely different topologies using the same routing daemon on the
same node. That should be representable in the database. But there maybe additional
routing daemons running on the mentioned gateways (batman(-adv), OSPF, BGP)
which may have a completely different set of neighbours or as well an overlapping
set. In the latter case it maybe good to know link metric of all routing protocols spoken
between 2 nodes.
Regards
Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20120513/9641750e/attachment.html>
More information about the Interop-dev
mailing list