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

[Mark Tinka]

On 13/Mar/18 18:47, adamv0025 at netconsultings.com wrote:

> 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

Okay, so just to be pedantic, fully-meshed RR's don't "reflect" routes
to each other (they can, but it's redundant).

But I get what you're trying to say...

> 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

Yes, understood.

So in our case, we are happy to hold several more paths this way within
our RR infrastructure in exchange for a standard, simple configuration,
i.e., a full-mesh amongst all RR's.

Having to design RR's such that RR1-Cluster-A only peers with
RR1-Cluster-B_Z, rinse repeat for RR2-* is just operational complexity
that requires too much tracking. Running the network is hard enough as
it is.

We are taking full advantage of the processing and memory power we have
on our x86 platforms to run our RR's. We don't have the typical
constraints associated with purpose-built routers configured as RR's.
It's been a long time since I had dedicated Juniper M120's running as
RR's - I'm never going back to those days :-).

Mark.