[c-nsp] OSPF+BGP and MPLS Q's

[adamv0025 at netconsultings.com]

> Peter Rathlev
> Sent: Monday, July 23, 2018 3:42 PM
> To: ringbit at mail.com
> 
> On Mon, 2018-07-23 at 12:23 +0200, ringbit at mail.com wrote:
> > Anyone else can give an opinion to those three questions?
> 
> Opinions are easy to give. :-) Authority is a different question
altogether. I
> spend my daytime in a place that started with just 6 PE routers and has
slowly
> grown to 51 over ~13-15 years. Still not a big number, but I have been a
part
> of it all the time and have learned some things the hard way.
> 
> We're an closed ("enterprise") IS-IS-based MPLS L3VPN network so things
> might not translate directly. We only have IGP links and loopbacks in
IS-IS,
> just above 200 routes in the global table currently. We around
> 7000 prefixes in BGP.
> 
> I'm also not sure I understand the first question. BFD is a way to
overcome
> certain failure scenarios if you need to use some kind of L2 transport
> between the routers. But the better way, since you ask, is to have two or
> more physically direct and diverse L3 links between the routers.
> 
> We have always been single area. Our small size considered this will most
> likely never be a problem. If the size of your network is within an order
of a
> magnitude of ours I see no reason at all to introducing the complexity of
> multi-area.
> 
> We started the network without route reflectors. When we grew to more
> than 20 PE routers we configured three existing PEs as RRs. This was a bit
> more complex than we wanted, so we eventually started using two Cisco
> 2901 as RRs. They have been with us since and are not breaking a sweat
> handling the ~7000 networks and ~17000 paths we have in BGP.
> 
> Having RRs really simplifies deploying new PEs. Big networks probably have
> even the deployment of new PEs fully automated, but would then choose
> RRs for scalability reasons.
> 
> If I were to start over I would implement RRs from the very start.
> 
> We use unique (type 1) RDs per PE and thus have all PEs see paths from all
> other PEs, not just the "best" path, giving us quick failover.
> 


This topic of RRs is actually very interesting,
At first networks where meant to be very decentralized to sustain attacks,
and the pendulum keeps on swinging back and forth on the
centralize/decentralize front -while the RR thing seems to be stable through
that. 
I guess one of the reasons is that using the RRs gives the control of the
scalability and robustness "sliders" of the solution to the operator.  
(in other words the scalability and robustness is agnostic to each other or
to the number of the BGP speakers in the network giving us the best possible
versatility)

1a) You can increase robustness by using different RRs for different
prefix-groups (or AFs) - the more the better robustness (and as a side
effect the solution will scale better).
1b) you can have 1 (non-resilient) or two and more RRs per prefix-group. 
2) And also for any of the AFs or prefix-groups you can have different
slices or "Planes" each carrying a subset of prefixes thus increasing the
scalability of the solution. 
3) If number of sessions per RR is a problem you can add more RRs per
AF-group (or per AF-group slice) each terminating just a subset of all BGP
sessions
    -then you end up with separate infrastructures of RR per 1b) or per 2). 

Each of these you can scale in or out independently depending on your
requirements.

Although I'd suggest you want to have 1a to at least divide Public Internet
prefixes and your internal VPN prefixes.
The 1b) is a given for anyone who's using RRs even if they are using just a
single prefix-group (i.e. at least 2 RRs for the whole network) 
  

adam

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