The MPLS-OPS Archive

[Danny McPherson <danny@ambernetworks.com>]

> Both, since disparate routing tables are necessary to keep overlapping 
> addresses in different VPNs from colliding.

Right.

> Jim has done more VPN stuff than I, but yeah, the seperate-set-of-RRs
> scheme is pretty common.  How is this BGP overlay topology different
> than an IPSec overlay?

I prefer the CE-based IPSEC stuff.  The difference should be 
obvious (e.g., the SP sees nothing beyond standard IP packets)

> >   or ASBRs, 
> 
> Not necessarily.      

If confederations are used.  But the pitches focuses on the 
LDP/BGP RR route.

> 
> > and the entire BGP topology for the VPN AF is 
> >   now non-congruent to the unicast BGP topology,
> 
> But it's a whole different AF - what does it matter?  

It's a BGP/TCP session that would otherwise not be necessarily.

> MPLS VPN BGP doesn't change any existing IPv4 topology, though. 

Nope, you just build a new control plane and need edge-to-edge
LSPs.

> You add complexity to a network as you add services; 

Sure, especially if they employ all of the existing core 
protocols -- which is where I have the problem.

> you don't have to
> change the parts of the underlying network that don't participat ein
> these services.  Not that I'm implying IPSec is any different, I just
> don't understand the point about incongruent topology being tha tbig a 

I don't recall saying IPSEC was any better, though it is 
edge-to-edge.  Of course, if there were an IP-based edge-to-edge
mechanism that encompassed both the data and signaling aspects 
it's certainly be better, especially if it didn't employ BGP 
and a bunch of stateful TCP stuff. 

The topology argument stems from the fact that the currently 
proposed peer-model VPNs employ existing protocols, but in 
manners which are non-congruent to the existing topologies, 
requiring additional session state, etc..

> I hope you're not implying that "Policies or mis-configurations could
> easliy break things" is inherent only to MPLS VPNs?   

Certainly not.  Though clearly, the more devices and protocols 
involved, the more complex things are.  The more complex (or 
is it convoluted?) things are the more likely they are to result 
in configuration or other operational errors.

> That's a nice list of bullets.  But how many of the above items are
> already in an SP network?  A god bunch of the BGP stuff is already
> there; ORF, for example, is useful for more than just VPN routes.  ANd 
> 'BGP Route Reflection or Confederations'?  You're the experienced
> operator, so you tell me - if you ran an SP network, would you do it
> *without* either one of these?  etc...

Nope, but I would deploy a different RR topology and 
dedicated routers for the task.
 
> And "core state" just flat out doesn't belong in that list, as
> the whole idea behind MPLS VPNs is to *avoid* core state.  

This is only if new BGP topologies are introduced for the 
VPN AF.
 
> I'm not arguing that your overall point is invalid; just that if
> you're going to list "the Evils of MPLS-VPN", then a lot of the above
> stuff doesn't belong.  

Ohh, and as for the list above.  I know several [very large] SPs
that only use:

 o BGP

at the moment.  Go figure...  There are indeed cool things that 
can be done with Route Refresh, MBGP, BGP-CAP and the like, but
VPNs isn't in my list..
 
> Lare enterprises run BGP.  They do difernet (and IMHO rather obscene)
> things with it, but it's there.  And I think you're not really arguing 
> that large SPs don't need BGP.
> 
> That leaves MPLS.  There are really 4 things MPLS gives you that IP
> doesn't
> 
> - removal of bgp in the core

And why is it that folks want to do this again?

> - BGP MPLS VPN

You can do this with IP, the folks with SOS (shiny object syndrome) 
seem to prefer the BGP/MPLS VPN stuff though.

> - MPLS-TE

ok.

> - circuit emulation

You can do this with IP, lots of folks have been doing it 
with IP for several years now -- including real time and 
TDM stuff.

> Removal of bgp in the core is useful; I know at least 2 large providers 
> who are very deliberately doing this becuase they have MPLS, or
> perhaps the other way around. 

And think back to why they want to remove BGP from the 
core!

> TE, it has been acknowledge, is useful.  

Agree.
 
> circuit emulation is another religious war.  personally, I think that
> if the majority of what you sell is L2 circuits, you should buy L2
> gear (FR/ATM switches) to do this with.  However, there have been
> overzealous folks on both sides of the fence (SP and vendor) who have
> convinced themselves that the primary use for an IP network is to
> emulate L2 transport; I don't agree.

I don't know.  Converging networks to a ubiquitous core transport 
while accommodating legacy services makes tons of sense in the SP/
Carrier space.  As for true circuit emulation, moving things like 
DS-n over IP/MPLS makes tons of sense because the grooming and 
service velocity gunk is a non-issue.  Not to mention the fact that 
things like idle suppression the like can make TDM emulation even 
more efficient.
 
> For a network to move from IP-only to offering MPLS VPN is not a small 
> task.  But is there really any difference between the incremental
> addition of MPLS VPNs to an already mpls-enabled network (per the
> first 2 points above) vs. the addition of managed CPE service to a
> pure IP network? 

Without a doubt, yes!

> Now you've lost me.  Either you've done a lot more thinking about this 
> than I have or you're reverting to marketing bullets.  How is MPLS VPN 
> not edge-to-edge?  It *has* to run on the edge.  I'm confused. 

Oh, it is, it just requires a bunch of gunk in between. 

> We've got that.  In fact, the same cisco product that can manage an
> IPSec network can manage an MPLS VPN network.  Do you have to use
> ours?  No.  But one certainly exists.

No, I meant a management system that configured everything and 
got rid of all the heavy dynamic gunk.
 
> But how is this different from requirements for things like 50ms
> restoration (which pretty much mandates APS)

None of the carriers in the US provision their transmission 
networks to meet the GR-253 50ms gunk.  This is the one place
think TE (FRR) is cool.

> or ability to build a
> full mesh between a given plane of core routers (which gets a lot
> easier with an ATM core)?

Sure.  That why TE makes more since the large NBMA cores, 
because you don't need the n*n adjacency gunk.

-danny

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