The MPLS-OPS Archive

[Eric Osborne <eosborne@cisco.com>]

On Sat, Mar 17, 2001 at 02:19:38PM -0700, Danny McPherson wrote:
> 
> > 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)
> 

The point I was hinting at is that the scalability work has to be done 
somewhere, either PE or CE.  Doing the config work on the PE will
scale better, since you have something like N*N connectivity between
PEs, rather than N*N between CEs.  Of course, if the amount of work
required to maintain a PE-PE full mesh of technology foo is more than
the amount of work required to maintain a full mesh of CE-CE with
technology bar, then this is no longer a clear-cut question of number
of nodes.

> > >   or ASBRs, 
> > 
> > Not necessarily.      
> 
> If confederations are used.  But the pitches focuses on the 
> LDP/BGP RR route.
> 

Yes; that's what I was assuming.  Certainly, confederations changes
the ASBR story somewhat. 

> > 
> > > 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.
> 

Yes.  I guess when you said 'topology', I was inferring "path your
data packets take", rather than "existence of new control-plane
stuff".  And depending on how you set things up, it may not be a new
BGP session, but just a new address family.

> > 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.
> 

Yes. 

Although just to throw my .02 in on a tangent, I've always found the
idea of "end-to-end LSPs" a bit misleading.  If you have a non-ATM
network (or just MPLS over PVCs) and are not running TE, then LSPs
look more like some sort of link-local ARP than they do end-to-end
paths.  The label merging inherent at every hop means there's not a
lot of 'string'-type connection from PE to PE.


> > 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. 

But anything that runs over IP in an SP core needs to use info derived 
from "BGP and a bunch of stateful TCP stuff".  MPLS-VPN is replicating 
an existing technology for its control plane, not adding a new one.

> 
> 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.
> 

Sure.  But again, none of this is inherent to MPLS-VPN.  Compare
managed CPE IPSec to MPLS VPN.  Comparing unmanaged CPE IPSec is a
little less accurate, becuase from the SP's perspective, there's no
work to be done.  But managing a customer's VPN for them can be
construed as one of those value-add things that salespeople like to
talk about.  That's why managed CPE IPSec has done well.

> > 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.

But some folks do that for IPv4 routing now; they're either re-using
existing dedicated RRs or deploying more of what they've already got.

>  
> > 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.

No, it isn't.  Only the edge routers know or care about VPN routes.
Routers which are not participating in VPN (not VPN RRs, not VPN PEs)
don't even know VPNs exist.  This applies to both core routers and
non-VPN edge routers.


>  
> > 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..

Let's be fair, here.  Your list of BGP features necessary for MPLS VPN 
are:

    o BGP VPN-IPv4 NLRI (w/RD & RT)
    o BGP Capabilities
*   o Multiprotocol BGP
    o BGP Route Refresh
    o BGP ORF
*   o BGP Route Reflection or Confederations
*   o BGP Extended Communities
+   o LDP 
+   o MPLS
*   o BGP 
    o Non-congruent BGP topology w/different VPN AF peerings
    o Core state (or alternative topology)
    o BGP Label
*   o super glue
+(maybe)    o edge-to-edge LSPs


I have starred the ones that I think are going to be in every SP
network, even those that have no MPLS.  Technologies that are going to 
be in an MPLS network used for something other than VPN (basic label
forwarding and TE, for sake of argument) are marked with a plus sign,
and are in addition to any already starred.

So it's not just 1 thing (BGP) vs. 15 things, it's more like 5 to 15.
Or perhaps 7-8 to 15.  

I'm not sure what 'super glue' is, but I bet it's in every network
with more than 2 routers...)

>  
> > 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?
> 

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)

- 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?)

> > - 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.
> 

I specifically said "BGP MPLS VPN", which you can't do wth just IP. :) 

> > - 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.
> 

Sure.  And like I said, I'm not a big fan of that as the primary
motivator for MPLS.  But it's there.  And it can be tied to TE to do
(I think) better circuit emulation than can be done over regular IP.

> > 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.
>  

Sure.  But if you do circuit emulation in your core, you eschew a lot
of the scaling properties associated with packet networks.  But you
have some valid points.

> > 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!
> 

I guess I'm still lost - what is the major difference?

> > 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. 
> 

So you don't really want 'edge-to-edge', you want 'edge-only'?
If your network is already running MPLS, then the addition of MPLS-VPN 
is in two places:
	1) edge routers (PEs)
	2) route reflectors (most likely)

So it's not edge-only.  But it's pretty close, and the non-edge bit is 
BGP RRs, which SPs know how to use.

> > 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.
>  

What 'dynamic gunk'?  You mean obviating BGP as a control plane by
assigning static labels to all the PE routers?  That's actually not a
bad idea..... 

> > 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.  

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

> This is the one place think TE (FRR) is cool.

TE is useful for other things, too; let's start a seperate thread on
that if you want to get into TE utility...:)

> > 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.
> 




eric

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