[c-nsp] BGP convergence in VRF vs. global routing tableon7600router

[Oliver Boehmer (oboehmer)]

Christian Bering <> wrote on Friday, October 19, 2007 3:45 PM:

>> Ok. So PE1 will receive many withdraws and/or updates and needs to
>> change the path from PE3 to PE2? Or will the next-hop stay the same?
> 
> The path will switch from one border router to another so the next-hop
> will change accordingly.

ok. 
 
>> Did you compare the convergence in a VRF to a convergence in an MPLS
>> environment in the global table? I.e. did you label-switch the BGP
>> packets in the global table, or used IP only?
> 
> Not tried label switching in the global table in the lab yet but it's
> on the list as the next thing to try. The amount of label allocation
> should be the same, though, right? So if that setup yields better
> convergence, we're down to BGP converging better in the global
> routing table than in a VRF.

If the next-hop changes, you will still need to update the FIB with a
new label, but I would expect this to be faster as there is no vrf
overhead (and I don't really have a feeling on this on this platform). 
f you don't bother carrying full BGP on your core/P nodes, you could
even consider getting rid of MPLS for global BGP by not advertising
labels for the "gateway" PE devices (i.e. the ones connecting to your
upstream).

> The whole point of my original questions was to get a feel for what to
> expect in such a setup before actually trying it in the lab. What
> would you expect to see?

Well, I honestly don't know. All the 2547bis designs asking for good
convergence ususally involve unique RDs so the distant PEs (PE1 in our
example) already has both paths available and is able to quickly switch
to alternate paths, but this is an expensive approach when we talk about
full Internet routing table.
I've never worked with Internet in a VRF, so can't add too much here. I
usually advise on not carrying the Internet table in a VRF as I don't
really see the practical benefit.

	oli