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.ti...@seacom.mu] 
Sent: Tuesday, March 13, 2018 2:36 PM
To: adamv0...@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, adamv0...@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.

_______________________________________________
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to