Neat idea!<p>Some technical details from clicking through to the github repo for their fork of BIRD, detailing the config and protocol changes you'd need to make for interoperability:<p>Change in BGP Configuration:
In each BGP protocol section you must set a role option. Currently, there
are 4 possible values for this option:
1) "provider" - neighbor is your upstream provider;
2) "customer" - neighbor is your customer;
3) "peer" - neighbor is your peer;
4) "internal" - neighbor is part of your AS or company (in case of multiple AS).
Without setting a role in BGP protocol section you will receive error message
from config parser.
Also you could set strict_mode option in BGP protocol section. In this scenario
BGP session with your neighbor will be established only if your neighbor also
support Roles and corresponding Role is correct.<p>BGP Protocol modification:
There are two main changes in BGP protocol behaviour:
1. BGP Update modification: to routes that were learned from upstreams or peers
add special non-transitive attribute “Local Announce” (BGP Path attribute code 19).
On links with upstreams and peers filter out routes with determined attribute;
2. BGP Open modification: to OPEN messages add new capability option "Role"
(Capability code 38), in which broadcast value of Role configuration option.
Establish connection only if speaker and its neighbor have appropriate pair of
Roles: (provider, customer), (customer, provider), (peer, peer), (internal, internal).
Shouldn't this be something that's proposed and implemented by the IETF, since BGP is an IETF standard?<p><a href="http://datatracker.ietf.org/wg/idr/charter/" rel="nofollow">http://datatracker.ietf.org/wg/idr/charter/</a>
Hi guys,<p>I am one of the guys responsible for this development.
We do mean to (at least) try to do draft with IETF.
We do realize that IETF process might feel funny and painful, but running the bgp the way it is even more painful.<p>Sort of trying to scratch our own itch.....
Wish us some luck, we will need it in quantities.