The MPLS-OPS Archive

[Danny McPherson <danny@ambernetworks.com>]

> Lemme just clear this up.  I am not arguing that MPLS should be
> deployed just for removal of BGP in the core.  But if MPLS is deployed 
> for other reasons (TE), then BGP is no longer _necessary_ in the
> core.  Why are folks doing it?
> 
> - easier to scale, especially with RRs (same BGP scaling properties,
> less nodes)

Not really, as now the BGP topology is not congruent to 
the data plane.  When you remove the ability for hierarchal 
iBGP architectures that are inline with the data plane (e.g., 
Route Reflection w/concave clusters) it's been shown that 
really bad things can easily happen. 

I mean, jeez, look at the BGP route oscillation stuff with 
'de facto' configurations doing simple things.  Of course, 
these things are inherent to any path vector protocol, I 
guess, but things like this only amplify them.
 
> - removal of core state (you don't seem to like dependence on a
> TCP-based protocol with core state for MPLS, surely you would agree
> that its removal from a non-MPLS-VPN core is also good?)

Though again, this requires that you create a BGP control 
plane non-congruent to the forwarding plane.  

The primary reason I see SPs wanting to remove BGP from the core 
is because of the convergence and instability properties of BGP.  

The point here I was trying to make is that a lot of this
is triggered by 500K, or even 1 million BGP paths in core routers,
and the processor, memory and capability set requirements it 
places on core devices.  BGP/MPLS VPNs only makes this worse, 
even if only deployed in PEs, especially because of the global 
impact a single router can have on the BGP, even routers in 
distant domains can suffer.

The fact that some BGP VPN mishap in a peers network can trigger
instability in the larger Internet scares me.
 
> I specifically said "BGP MPLS VPN", which you can't do wth just IP. :) 

Sure you can, just run MPLS over GRE, right?  :-)

> I'll defer to you on this point, although I think 'none' is perhaps a
> bit strong of a statement.

Let me scope it .. none of the largest 5 [largest 5 in my mind, 
nothing scientific about it].  Think about it, this requires that 
rings be no larger than n miles, where the aggregate prop delay
of n [minus a few ms for nodal processing] must be less than 50ms.
And on the protect [longer] path around the ring!  

It requires a lot more SONET ports as well (I guess this is why the 
manufacturers wrote the spec as such :-).  Provisioning transmission 
facilities where rings converge in <50ms, especially in the midwest, is 
difficult at best.  100-200ms seems to be more common.


-danny

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml