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

[Mark Tinka]

On 11/Mar/18 12:50, Job Snijders wrote:

> Have you considered the downsides of sharing a Cluster-ID across
> multiple boxes,

IIRC, the biggest issue with this was if the RR was in-path (as it used
to be back in the days - and in some networks today - when core routers
doubled as RR's), and there was no physical link between clients and all
RR's.

In our network, RR's in the same PoP sharing a single Cluster-ID is fine
because every client has a redundant physical link toward each RR, and
each client has an iBGP session with all RR's. The benefit of using the
same Cluster-ID for the RR's in the same PoP is much reduced overhead
per RR device, as each RR only needs to hold one copy of NLRI.

>  and do you have any arguments to support why it is
> overkill?

Not practical ones, just theoretical ones based on the MCID text. To
badly over-simplify the objective, it would seem that the idea is to
limit the amount of routing clients can hold for each other's NLRI. It's
likely some networks may have a use-case, but from my viewpoint, that
would create an inconsistent view of the iBGP state within a routing
domain from a per-device perspective.

On that basis alone, I have not considered any other advantages MCID
could have. But, happy to hear about them, if any, of course...


> Are you at least using separate BGP sessions for each address families?

It wasn't apparent to me that there was any other sensible way :-).

I've been using BGP Peer/Policy Session Templates on IOS and IOS XE
since they were introduced back in 2003. These lend themselves naturally
well to breaking one's BGP setup into per-session and per-policy
architectures. A bit more verbose than the classic way of doing things,
but that doesn't bother me.


> Are you using optimal route reflection, or how have you mitigated
> negative effects caused by the lack of ORR?

So still some love & hate going back & forth between me and Cisco on ORR
support for CSR1000v/IOS XE. They have support on IOS XR (for the
ASR9000) and XRv.

Juniper has supported ORR for some time now, as has Nokia (ALU).

For now, we are mitigating the effects of a lack of ORR on CSR1000v,
which specific to a few "off-net" PoP's. As of last May 2017, Cisco
expected ORR for CSR1000v to appear in 16.9(1), which is slated for July
2018. I'm still waiting for confirmation from them if this is still on
track.

Why don't we just move to XRv? Well, for some reason, we find the
IOS/IOS XE BGP infrastructure "simpler" than IOS XR, for RR purposes.
Yes, IOS XR is probably more modern, elaborate and flexible than classic
IOS/IOS XE, but for us, that only works okay for peering or edge
applications. For an RR use-case, it's overkill as our RR policy design
is already very intricate as it is, without all the granularity of RPL.

Why don't we just move to Juniper's vRR - well, we did consider it back
in 2014, but they were too slow and we needed a solution quickly. But
for the same reasons as with IOS XR, while more modern, elaborate and
flexible than classic IOS/IOS XE, it would have been a lot more
cumbersome to use for an RR application given the nature of our iBGP
domain. Juniper's BGP implementation is, as with IOS XR, fine for us in
peering and edge scenarios. In an RR application, we need a BGP
implementation that is simpler than our iBGP policy.

Mark.