[j-nsp] RR cluster

[Pavel Lunin]

> I would strongly advise against the previous suggestion of not running
> iBGP between the routers.  While the topology in particular may
> function without it, the next person to come along and work on the
> network may not expect it to be configured
Hmm... really depends. I can easily recall scenarios, where an iBGP
between RRs would increase chances of service outage.

Say, RRs are offline and don't pass traffic at all. They just don't (or
rather, even must not) have any "their own" routes to attract traffic.
The lack of inter-RR exchange is just an additional security (and
simplicity) measure. No session means no routing-policy, no leakage of
something (e. g. due to software bugs).

Imagine you use RRs to inject initially static routes into the network
(flowspec, blackhole, whatever). There is no reason to share this
between RRs, instead, you want both reflectors to redistribute it
independently.  If your forget to configure these statics on both RRs
(very common mistake), than, having an iBGP between them, you will still
see two copies of the route in the network despite you have configured
it only once. Thus you won't suspect that an RR failure will lead to a
withdrawal of these routes. So I personally would recommend to filter
such updates between RRs even when you have reasons for a session
between them.
> inconsistent with standards and best practices and may, thorough a
> seemingly unrelated change in topology, break things horribly. 
BTW, I don't really believe there exists a common standard or
best-practice prescribing to do this.