[Babel-users] Babeld Team ID ( AS number like )

Saverio Proto zioproto at gmail.com
Sun Mar 24 18:13:00 UTC 2013


> 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



More information about the Babel-users mailing list