The MPLS-OPS Archive

[jim guichard <jguichar@cisco.com>]

At 10:44 17/03/2001 -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?

certainly enough to satisfy the VPN requirements of the SP.

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

actually, both.

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

well, lets assume that most SPs will deploy route reflection and/or 
confederations then you are correct to assume that not all BGP speaking 
routers have to carry VPN routes. So this leaves the RRs and/or 
confederation ASBRs as the impact point rather than all BGP speaking 
routers as you suggest. This leads to the next point :)

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

the existing IPv4 sessions can carry VPNv4 NLRI as well as IPv4 and the 
route reflectors can reflect IPv4 and VPNv4 prefixes.

>   Now, this topology has it's own set of Route Reflectors,
>   or ASBRs, and the entire BGP topology for the VPN AF is
>   now non-congruent to the unicast BGP topology, and an
>   additional set of [stateful] BGP peering sessions must be
>   configured and maintained by the operator.

this depends on how you deploy it - sure, you can use different route 
reflectors for VPNv4 but you can also use existing IPv4 route reflectors. 
Now, depending on how big your VPN customer base becomes, it may be 
desirable to deploy separate RRs for VPNv4 reflection but it is not a 
requirement of the architecture.

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

I think the real reason is that BGP has been proved to be the best protocol 
for distribution of large amounts of routing information - its convergence 
properties are as you say not as good as most IGPs but that was not the 
main purpose of the protocol. To speed up convergence we can tune BGP with 
various timers ..

>   However,
>   there are a number of issues with this:
>
>   o all the recommended topologies are non-congruent to the
>     existing BGP topologies
>

which topologies exactly do you mean ? there are many different topologies 
and ways to deploy BGP.

>   o you really don't know if the route was processed by the
>     target PEs, just that your peer acknowledged receiving the
>     segments.

this is not an argument as TCP has always assumed that the receiving peer 
has processed the data through receipt of an acknowledgement.

>Policies or mis-configurations could easliy
>     break things.

so could mis-configuration of your IP routing structure so I do not see how 
this is any different.

>   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.
>
>   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.
>   As well, I'm not sure that _all these enterprise folks, much
>   less SPs, even need MPLS (or BGP).
>
>   IMO, something expressly designed for this purpose would
>   likely be more scalable and much simplier.  Say:
>
>   o a true edge-to-edge solution

I would class MPLS/VPN in this category - what specific solution do you 
have in mind ?

>   o a NMS to configure and manage the edge devices
>   o employ whatever transport substrate (e.g., MPLS, IP
>     for edge-to-edge) folks wanted to use

this is also possible with MPLS/VPN - you do not have to run MPLS in the 
backbone if you would prefer to run GRE tunnels or some other type of 
encapsulation mechanism.. Jim

>-danny "who wholeheartedly believes that just because something
>         makes a good hammer, it doesn't make everything a nail"
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml



Jim Guichard CCIE #2069
Technical Advisory Consultant EMEA

+44 208 756 8806
Mobile: +44 7802 809763

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