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:
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.
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).
Invention and prototyping come before IETF submission. But some people think the IETF process is kind of broken, especially when it comes to open source.
I don't know what kind of broken you are reffering to, but it's painful to see what "they" (the idr wg) are doing with BGP. Most RFC contain something like:
"since BGP is such a widely used and stable protocol, let's add more stuff to it!"
And the go on changing semantic of existing encodings in a way that forces unimaginably hairy hack unto any reasonable existing implementation (see flowspec, see multiprotocol, see add-path, ...)
I'd rather have tens of tiny protocols running on network, that one such BGP bug-carrier.
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.
Sort of trying to scratch our own itch.....
Wish us some luck, we will need it in quantities.
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:
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.
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).