> Hmm... yes, but it could be done in a backwards-compatible manner, by > adding a new route attribute. The compatibility would not be perfect, > as old nodes would discard the new attribute, so a route learned > through an old router would appear as having no attribute. > > If we do that -- a few questions. How do we call the new attribute? > Team-id is a little too specific, I've got a mind to call it the > "opaque attribute", or, following BGP, the community id. > > What should the new attribute be like? Should it be a 16-bit integer, > a 32-bit integer, a 64-bit bytestring, or a bytestring of arbitrary > length? Should it have internal structure? Should multiple opaque > attributes be allowed for a single route? Should it be explicitly > marked as transitive, as in BGP, or is that overkill?
Well, we are doing something experimental here in Ninux, using an IGP like Babel in place of a classical BGP setup. Don't ask why :) In one side we have young nerds that never used BGP and are lazy to learn the old good protocols (read Gioacchino here). The the other side we want to test if it is possibile to achieve this goal with simpler setups and an IGP protocol like babeld with a elegant implemetation that is rock solid on embedded devices. We have routers at the border of different domains that speak both OLSR and babeld. The Babeld domain in an overlay VPN, a simple LAN where you see all the other boarder routers (that speak both protocols). A single domain might have more border routers, so to avoid loops in redistribution of routes from a protocol to another (olsrd into babeld and babeld into olsrd) we need to identify the autonomous system these routes are coming from. The "no patch required" idea is to use the fact that every babeld router could be configured to ignore the routes announced by other babeld routers in the same AS. To do this we filter on the router_id route attribute. But this requires effort in configuration and it is error prone. So the idea is to ignore routes from my same autonomous system because I am learning this stuff already via OLSR. It would be enough to define an AS for each OLSR domain, and configure the babeld routers to 1) tag routes with the AS 2) discard routes with same AS as theirs. I would suggest to stick to 32-bit integer, that is the standard both for AS numbers (the new ones) and the BGP communities. Should multiple opaque attributes be allowed for a single route? yes, so we can use this to redistribute BGP communities into babled in the future. Should it be explicitly marked as transitive, as in BGP, or is that overkill? It should be transitive ciao, Saverio _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
