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

[adamv0025 at netconsultings.com]

Ok you’re still missing the point, let me ty with the following example. 

Now suppose we both have: 
pe1-cluster-1 sending prefix X to rr1-cluster1 and rr2-cluster1 and these are then reflecting it further to RRs in cluster2

Now in your case: 
rr1-cluster2 receives prefix X from both rr1-cluster1 and rr2cluster1 –so how may paths will it keep? yes 2
rr2-cluster2 receives prefix X from both rr1-cluster1 and rr2cluster1 –so how may paths will it keep? yes 2

In my case:
rr1-cluster2 receives prefix X from rr1-cluster1 –so how may paths will it keep, yes 1
rr2-cluster2 receives prefix X from rr2-cluster1 –so how may paths will it keep, yes 1 

adam

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

From: Mark Tinka [mailto:mark.tinka at seacom.mu] 
Sent: Tuesday, March 13, 2018 2:36 PM
To: adamv0025 at netconsultings.com; 'Saku Ytti'
Cc: 'Job Snijders'; 'Cisco Network Service Providers'
Subject: Re: [c-nsp] IOS-XR BGP RR MCID (Multiple Cluster ID)


On 13/Mar/18 13:04, adamv0025 at netconsultings.com wrote:
Keeping RR1s separate from RR2s is all about memory efficiency,

That memory saving could now be entering the real of "extreme", but hey, your network :-)...


	
The same rationale is behind having sessions between RRs as non-client sessions.
- In combination with separate RR1 and RR2 infrastructures each RR (RR1/RR2) in the network learns only one path for any single homed prefix. 
- If I’d have RR1s and RR2s all mixed in a full-mesh then each RR would get 2 paths 
That is double the amount of state I’d need to keep on every RR in comparison with separate RR1 and RR2 infrastructures.

The actual routes the RR's would exchange with one another in a shared Cluster-ID scenario would be the routes they originate. Provided you are a network that does not de-aggregate, you're looking at just whatever allocations you obtain from your favorite RIR. Not about to break the memory bank (pun intended, hehe) compared to the state of the global Internet routing table.



If sessions between RRs are configured as client sessions AND 

Don't know why you'd do that.

Inter-/intra-RR sessions should not be clients, IMHO.

But like I said, your network...

Mark.