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

[adamv0025 at netconsultings.com]

Hi,

The point' I'm trying to make is that I don't see a reason why RR1 and RR2 in a common cluster should have a session to each other and also why RR1 in one cluster should have session to RR2s in all other clusters. 
(and if RR1 and RR2 share a common cluster ID then session between them is a complete nonsense). 
Then if you go and shut PE1's session to RR1 and then go a shut PE2's session to RR2 then it's just these two PEs affected and well what can I say you better think twice next time or consider automation.  
One can't possibly bend the backbone architecture out of shape because of all the cases where someone comes in a does something stupid (this complexity has to me moved somewhere else in my opinion -for instance to a system that won't allow you to commit something stupid). 

Regarding the scale - well there are setups there with couple millions of just customer VPN prefixes.  
  
Regarding the Cluster-IDs - yes these are used for loop prevention but only among RRs relying routes to each other -if  PE is in the loop then Originator-ID should do the job just fine. 
 

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

> -----Original Message-----
> From: Saku Ytti [mailto:saku at ytti.fi]
> Sent: Monday, March 12, 2018 10:43 AM
> To: adamv0025 at netconsultings.com
> Cc: Job Snijders; Mark Tinka; Cisco Network Service Providers
> Subject: Re: [c-nsp] IOS-XR BGP RR MCID (Multiple Cluster ID)
> 
> Hey,
> 
> 
> RR1---RR2
> |           |
> PE1----+
> 
> 
> 1) PE1 sends 1M routes to RR2, RR2
> 
> CaseA) Same clusterID
> 1) RR1 and RR2 have 1M entries
> 
> CaseB) Unique clusterID
> 1) RR1 and RR2 have 2M entries
> 
> 
> 
> Cluster is promise that every client peers with exactly same set of RRs, so
> there is no need to for RRs to share client routes inside cluster, as they have
> already received it directly.
> 
> 
> Of course if client1 loses connection to RR2 and client2 loses connection to
> RR1, client<->client2 do not se each other's routes.
> 
> For same reason, you're not free to choose 'my nearest two RR' with same
> cluster-id, as you must always peer with every box in same cluster-id. So you
> lose topological flexibility, increase operational complexity, increase failure-
> modes. But you do save that sweet sweet DRAM.
> 
> 
> Most blogs I read and even some vendor documents propose clusterID to
> avoid loops, I think this is the real reason people use them, when RR was
> setup, people didn't know what clusterID is for, and later stayed committed
> on that initial false rationale and invented new rationales to justify their
> position.
> 
> Premature optimisation is source of great many evil. Optimise for simplicity
> when you can, increase  complexity when you must.
> 
> 
> 
> On 12 March 2018 at 12:34,  <adamv0025 at netconsultings.com> wrote:
> >> Job Snijders
> >> Sent: Sunday, March 11, 2018 12:21 PM
> >>
> >> Folks - i'm gonna cut short here: by sharing the cluster-id across
> > multiple
> >> devices, you lose in topology flexibility, robustness, and simplicity.
> >>
> >
> > Gent's I have no idea what you're talking about.
> > How can one save or burn RAM if using or not using shared cluster-IDs
> > respectively???
> > The only scenario I can think of is if your two RRs say RR1 and RR2 in
> > a POP serving a set of clients (by definition a cluster btw) -if these
> > two RRs have an iBGP session to each other - which is a big NONO when
> > you are using out of band RRs, no seriously.
> > Remember my previous example about separate iBGP infrastructures one
> > formed out of all clients connecting to RR1 in local POP and then all
> > RR1s in all POPs peering with each other in full mesh and then the
> > same infrastructure involving RR2s?
> > Well these two iBGP infrastructures should work as ships in the night.
> > If one infrastructure breaks at some point you still get all your
> > prefixes to clients/RRs in affected POPs via the other infrastructure.
> > That said both of these iBGP infrastructures need to carry the same
> > set of prefixes, so the memory and cpu resources needed are
> > proportional to the amount of information carried only.
> > -but none of these need to carry the set of prefixes twice, see below.
> >
> > Yes you could argue if A loses session to RR1 and B loses session to
> > RR2 then A and B can't communicate, but the point is PEs just don't
> > lose sessions to RRs -these are iBGP sessions that can route around,
> > so the only scenario where this happens is misconfiguration and trust
> > me you'll know right away that you broke something.
> > Then you can argue that ok what if I have A to RR1-pop1 to RR1-pop2 to B
> > AND  A to RR2-pop1 to RR2-pop2 to B   AND  say RR1-pop1 as well as RR2-
> pop-2
> > fail at the same then A and B can't communicate.
> > Fair point that will certainly happen, but what is the likelihood of
> > that happening? Well it's MTBF of RR1-POP-1 times MTBF of RR1-POP-1
> > which is fine for me and I bet for most folks out there.
> >
> >
> > adam
> >
> > netconsultings.com
> > ::carrier-class solutions for the telecommunications industry::
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> 
> --
>   ++ytti