Hi,
from an architectural point of view this patch is one of many that will help us migrating from an iBGP-only datacenter to an eBGP-only datacenter so the idea is to have a feature that is as simple as possible with almost no implications that can be turned on during the migration and then off after it. A confederation would have a similar effect but would have other side effects and would also require to change things in other places, leading to a maintenance window we are actually trying to avoid with these set of patches.
I am going to go a bit more in detail in a talk at NANOG71 in a couple of weeks, but let me try to summarize it here.
The patches in question are:
By combining the patches above we are able to migrate a full POP from iBGP with route reflectors to an eBGP-only setup without intervention and without having to drain POPs:
1. The patch `Secondary remote AS support for protocol BGP ` let's us configure the devices ahead of time to accept OPEN messages from different AS's so we don't have to bother synch'ing changes.
2. The `Allow exchanging LOCAL_PREF with eBGP peers` patch allows us to keep doing operations as we do now regardless of if the POP is formed by eBGP or iBGP speakers.
3. And for the last two patches let's look at this scenario:
/---- spine00 (AS65000)
leaf00 (AS12345)
\---- spine01 (AS12345)
Prefix A coming from the spines:
from spine00:
protocol: eBGP
AS PATH: 65000 $AS_PATH
from spine01:
protocol: iBGP
AS PATH: $AS_PATH
a. The patch "Implement iebgp_peer mode" helps us with the eBGP vs iBGP comparison. It doesn't try to do much else.
b. Now that eBGP vs iBGP is no longer a concern for this set of peers we need to fix the AS_PATH or the one from spine01 will be shorter and, this, win the election. This is where the patch "Implement skip_private_as_path_prefix" comes in. Instead of manipulating the iBGP speaker to prepend some AS we would rather skip the leading private AS's in the eBGP speaker. The reason is that as we have many spines so you would have to synch the changes so you wouldn't send all your traffic via only one (or alternatively schedule a maintenance which we are trying to avoid).
So now with all the features in place we can:
1. Ahead of time, enable all the features; local-pref over eBGP, have current and future AS configured, skip leading private AS's and compare eBGP as iBGP in the corresponding sessions.
2. During the maintenance change "local as" to the new private AS, switch by switch, causing only a small BGP session flap with no other implication.
And this is how we are migrating from iBGP to eBGP without human intervention and without having to drain POPs. Once migration is complete we can remove "compare_as_ibgp" flag.
In summary, I am not sure how useful some of these features could be in a permanent design, it might allow people to build `confederation-like` setups that are a bit simpler than using confederations but our goal is to have a path to migrate POPs autonomously without having to put them in maintenance mode. I understand these features are quite "temporary" and you might be tempted to dismiss them due to their nature but I think they are quite useful in production scenarios as they can simplify operations dramatically.
Regards.