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

[Mark Tinka]

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

> If RR1s and RR2s never talk to each to each other then it doesn't matter
> whether they have common or unique Cluster-IDs

Agreed. But in our case, they do.


> Job is right, you should at least use separate TCP sessions for different
> AFs,

Which BGP Session/Policy templates lend themselves naturally to, already.


>  but if you have Internet prefixes carried by VMPv4 then you're still at
> danger, unless you carve up a separate BGP process or iBGP infrastructure
> for Internet prefixes, yes the BGP Attribute Filter and Enhanced Attribute
> Error Handling should keep you relatively safe but I wouldn't count on it
> (it's still not an RFC and I haven't dig into it for years so not sure where
> are vendors at with addressing all the requirements in the draft).

We don't do Internet in a VRF.


> Internet is a wild west with universities advertising unknown attributes and
> operators prepending their AS 255+ times and you can only hope that any of
> such events will bring your border PE sessions down and actually won't be
> relied to your RRs which then start dropping sessions to all clients or
> restarting BGP/RPD processes...
> Hence my requirement for dedicated iBGP infrastructure for Internet
> prefixes.     

Our main business is regular Internet. VPNv4/VPNv6 accounts for not even
a rounding error in % terms on our network.

That said, it is useful to run as late as you possibly can code on your
edge routers and RR's to protect yourself against dodgy attributes or
unexpected NLRI behaviour.



> One fact that people usually overlook with ORR in MPLS backbones is that ORR
> actually requires prefixes to be the same when they arrive at the RRs so RRs
> can ORR on the best and second best to a particular set of clients. 
> And my experience is that usually operators are using Type 1 RDs in their
> backbones (so PE's-RID:VPN-ID format) -a that was the only way how to get
> ECMP or BGP-PIC/local-repair working ages before Add-Path got introduced.
> And in case of Type 1 RDs the ORR is useless as RRs in this case are merely
> reflecting routes and are not performing any path selection on behalf of
> clients.
> So the only way how to make use of ORR is to completely change your RD plan
> to Type 0 RDs VPN by VPN (maybe starting with Internet VRF) and introduce
> add-path as a prerequisite of course. 

We don't run Internet in a VRF, so shouldn't have that concern.

As soon as ORR is available on the CSR1000v, I'll provide some feedback
on its performance in our scenario.

Mark.