The MPLS-OPS Archive

[Eric Osborne <eosborne@cisco.com>]

On Sat, Mar 17, 2001 at 10:44:40AM -0700, Danny McPherson wrote:
> 
> > I am not sure which solution you refer to here but the MPLS based VPN 
> > architecture provides the ability to deploy infinite numbers of customers, 
> 
> Infinite?
> 
> > it all depends on how you design and deploy the architecture. From my own 
> > experience, I have seen several hundreds of routing tables work just fine 
> > on one PE device.
> 
> Routing tables or forwarding tables, presumably the latter.
> 

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

> > Now I admit, my main experience is with Service Providers 
> > rather than Enterprise but I can see some benefits to MPLS based 
> > solutions within the Enterprise such as TE. 
> 
> So let me pose a question for the BGP/MPLS VPN folks...  
> 
> o Have you done any analysis on how this [infinite] number 
>   of BGP VPN-IPv4 NLRI impact's the BGP core in SP networks?
>   After all, just because a bunch of the BGP routers don't 
>   need to base forwarding decisions on the VPN stuff, they 
>   still have to process UPDATEs and store the NLRI in the
>   respective BGP RIB(s) throughout the network.  I don't know 
>   of many service providers that are happy with convergence 
>   attributes of BGP as is, much less with a lot of additional
>   stuff piggybacking.
> 
> o If your response is "It's not in the BGP core of the SP
>   network" then I'm guessing that you've told folks it'll
>   only scale [or it'll scale infinitely] if you employ an 
>   'overlay' BGP topology for VPN-IPv4 route dissemination.

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?

>   Now, this topology has it's own set of Route Reflectors, 

Yes

>   or ASBRs, 

Not necessarily.      

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

> and an 
>   additional set of [stateful] BGP peering sessions must be
>   configured and maintained by the operator.  
> 

Yes.  But in IPSec, an additional set of IPSec tunnels must be
configured by *someone*.  Either the customer or the provider (in case 
of managed CE), but privacy over a public network requires etra
config.  There's no way to get around that.

>   Now, the whole point of employing BGP for this purpose in 
>   the first place was to reliably get a VPN route from one 
>   PE in the network to another PE (or set of PEs) and the 
>   fact that BGP is already deployed makes it easy.  However, 
>   there are a number of issues with this:  
> 
>   o all the recommended topologies are non-congruent to the 
>     existing BGP topologies
>  

MPLS VPN BGP doesn't change any existing IPv4 topology, though.  You
add complexity to a network as you add services; 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 
deal.

>   o you really don't know if the route was processed by the 
>     target PEs, just that your peer acknowledged receiving the 
>     segments.  Policies or mis-configurations could easliy 
>     break things.
> 

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

>   o the auto-discovery stuff requires [in multicast lingo]
>     dense flooding of the update within the AS .. or manual 
>     intervention with BGP Route Refresh after policies changes
>     and/or ORF stuff.
> 

True.  But adding nodes to an IPSec mesh, or a FR/ATM VC topology
requires manual intervention, too.  MPLS VPN can require far less.  

>   o additional security..  ha.
> 
>   o the whole point again was because it's simple.  Let's have 
>     a look at the components of simple:
> 
>     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
>     o edge-to-edge LSPs
> 
>   There are a few others, but I think folks get the point.  

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

And "core state" just flat out doesn't belong in that list, as
the whole idea behind MPLS VPNs is to *avoid* core state.  

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.  

>   As well, I'm not sure that _all these enterprise folks, much
>   less SPs, even need MPLS (or BGP).
> 

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
- BGP MPLS VPN
- MPLS-TE
- circuit emulation

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. 

We're already talking about MPLS VPN.  

TE, it has been acknowledge, is useful.  

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.

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? 

>   IMO, something expressly designed for this purpose would 
>   likely be more scalable and much simplier.  Say:
> 
>   o a true edge-to-edge solution

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.  

>   o a NMS to configure and manage the edge devices

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.

>   o employ whatever transport substrate (e.g., MPLS, IP
>     for edge-to-edge) folks wanted to use

True.  I've had customers who wanted to run MPLS VPN at the edge but
pure IP transport in the core, so have contemplated a full mesh of GRE
tunnels between MPLS VPN PEs; I think is silly.  So I agree - to some
extent, the requirement of services to be run across the network
determine the underlying transport protocol.

But how is this different from requirements for things like 50ms
restoration (which pretty much mandates APS) or ability to build a
full mesh between a given plane of core routers (which gets a lot
easier with an ATM core)?


> 
> -danny "who wholeheartedly believes that just because something 
>         makes a good hammer, it doesn't make everything a nail"

I agree.  Quite honestly, I don't really care what my customers run
for a VPN solution; I'll support it.  You work for a vendor now, you
can't tell me you don't hold the same beliefs?  If people stop using
MPLS VPN, it will die off, just like Apollo and EGP and so on.  But
the same argument holds true for IPSec.

Bottom line - there are multiple ways to do VPNs.  All of these ways
are useful, all of them are different, and all of them that I know of
require a fair bit of work on somebody's part.  But the existence of
more than one way to skin a cat does not mean the other cat-skinning
methods are bad.




eric

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

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