[c-nsp] IOS-XR BGP RR MCID (Multiple Cluster ID)

[adamv0025 at netconsultings.com]

> Job Snijders
> Sent: Sunday, March 11, 2018 12:21 PM
> 
> Folks - i'm gonna cut short here: by sharing the cluster-id across
multiple
> devices, you lose in topology flexibility, robustness, and simplicity.
> 

Gent's I have no idea what you're talking about. 
How can one save or burn RAM if using or not using shared cluster-IDs
respectively??? 
The only scenario I can think of is if your two RRs say RR1 and RR2 in a POP
serving a set of clients (by definition a cluster btw) -if these two RRs
have an iBGP session to each other - which is a big NONO when you are using
out of band RRs, no seriously. 
Remember my previous example about separate iBGP infrastructures one formed
out of all clients connecting to RR1 in local POP and then all RR1s in all
POPs peering with each other in full mesh and then the same infrastructure
involving RR2s? 
Well these two iBGP infrastructures should work as ships in the night. If
one infrastructure breaks at some point you still get all your prefixes to
clients/RRs in affected POPs via the other infrastructure. 
That said both of these iBGP infrastructures need to carry the same set of
prefixes, so the memory and cpu resources needed are proportional to the
amount of information carried only. 
-but none of these need to carry the set of prefixes twice, see below. 

Yes you could argue if A loses session to RR1 and B loses session to RR2
then A and B can't communicate, but the point is PEs just don't lose
sessions to RRs -these are iBGP sessions that can route around, so the only
scenario where this happens is misconfiguration and trust me you'll know
right away that you broke something. 
Then you can argue that ok what if I have A to RR1-pop1 to RR1-pop2 to B
AND  A to RR2-pop1 to RR2-pop2 to B   AND  say RR1-pop1 as well as RR2-pop-2
fail at the same then A and B can't communicate. 
Fair point that will certainly happen, but what is the likelihood of that
happening? Well it's MTBF of RR1-POP-1 times MTBF of RR1-POP-1 which is fine
for me and I bet for most folks out there. 


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::