The MPLS-OPS Archive

["Donkin, Richard" <rdonkin@orchestream.com>]

> -----Original Message-----
> From: Marinzulich, Matias [mailto:Matias.Marinzulich@comsat.com.ar]
> Sent: Fri 15 December 2000 13:11
> To: mpls-ops@mplsrc.com
> Subject: RE: MPLS VPN Scalability
> 
> 
> The main scalability problem that I can see is the config of routing
> protocols (with you customer) in the edge. Think that you 
> will have a lot of
> customer in a same edge router, customers that will want run distints
> routing protocols, for each of this protocols you will need 
> 'split' the
> configuration in several VPNs. I'm see that is the critical 
> point, a same
> IGP split in several (may be thousand) VPNs. 
> 
> Matias.-

This is true - however, you can add a new PE if the routing load on the
first PE becomes too much, as you'd expect.  As for configuring these
routing protocols, you might want to investigate provisioning tools that
configure these details automatically :)

Richard
-- 
rdonkin@orchestream.com                   http://www.orchestream.com
Tel: +44 (0)20 7348 1507 (direct)         Orchestream Ltd.
     +44 (0)20 7348 1500 (switchboard)    Avon House, Kensington Village,
Fax: +44 (0)20 7348 1501                  Avonmore Road
>>>> IP Service Activation >>>>           London W14 8TS, UK
 
> 
> 
> > -----Mensaje original-----
> > De:	Donkin, Richard [SMTP:rdonkin@orchestream.com]
> > Enviado el:	Viernes 15 de Diciembre de 2000 8:07 AM
> > Para:	'Eric A. Voit'
> > CC:	mpls-ops@mplsrc.com
> > Asunto:	RE: MPLS VPN Scalability
> > 
> > > -----Original Message-----
> > > From: Eric A. Voit [mailto:eric.a.voit@verizon.com]
> > >
> > > Yihan,
> > > 
> > > There are two scalability issues I know of:
> > > 
> > > The first is Operations related: how you identify and 
> > > troubleshoot transient
> > > network problems.  This to me is more of an RSVP or CR-LDP 
> > > issue.  If the
> > > network state is constantly changing based on a dynamic 
> > > reconfiguration of
> > > forwarding paths and/or resource availability, and there 
> is a network
> > > problem, how do you figure out what happened after the fact?
> > >
> > > The reason this is a scalability issue is that small MPLS VPN 
> > > networks can
> > > be statically established (and therefore avoid this 
> problem entirely).
> > > However MPLS VPN networks will eventually become too big 
> to be managed
> > > statically (and therefore requiring CR-LDP / RSVP).  As a 
> > > carrier, I can see
> > > a path to provision such large scale services -- but I am 
> > > afraid I have no
> > > idea how to identify, locate, diagnose, and resolve 
> troubles when the
> > > network state changes so quickly that the trouble could be 
> > > hidden before the
> > > troubleshooting begins.  This issue was faced by 
> traditional routing
> > > protocol developers many years ago.  If anyone knows of 
> > > solutions for MPLS
> > > VPNs, please send them along :-)
> >  
> > This is a traffic engineering issue, not specific to MPLS VPNs but
> > affecting
> > all sorts of traffic engineered networks.  While TE is very 
> valuable in
> > larger networks, it is quite possible to roll out MPLS VPNs 
> today without
> > TE, as quite a number of service providers are doing.  Given a
> > sufficiently
> > large overprovisioned optical core, you may not need to do 
> much traffic
> > engineering.  However, if you do require TE, with or 
> without MPLS VPNs,
> > the
> > ability to monitor and log what happened with the RSVP or 
> CR-LDP paths is
> > important, as you point out.  (I'm not sure why basic LDP 
> alone would not
> > scale to very large deployments, since it is quite simple and scales
> > alongside the IGP - please advise if this is what you mean!)
> > 
> > MPLS VPNs (as specified by RFC 2547) are already quite 
> scalable - each PE
> > only has to carry the VPN routes for sites to which it 
> connects, so if a
> > particular POP must serve twice as many sites you can 
> simply add another
> > PE,
> > which can have a different set of VPN routes for the 
> customer that it
> > serves.  So the PEs are not a scalability limit w.r.t VPN router
> > 
> > The P routers don't even see the VPN routes at all, they 
> only carry IGP
> > routes - so they can scale very easily.
> > 
> > Another scalability issue is BGP - in smaller MPLS VPN 
> roll-outs (in terms
> > of number of PEs, not number of sites) it's possible for the PEs to
> > directly
> > peer using iBGP, but this must be moved to a more scalable 
> route reflector
> > structure for large VPN roll-outs, so that the number of 
> BGP peers for
> > each
> > PE is reduced.  However, this is already a well known 
> practice in the BGP
> > world.
> > 
> > Finally, a significant but often overlooked issue is scalability of
> > provisioning MPLS VPNs - while this is less labour intensive than
> > provisioning ATM or Frame Relay, since there is no need for 
> circuits,
> > there
> > are still a lot of commands to be entered.  Most providers 
> are looking
> > towards automated provisioning systems for MPLS VPNs and associated
> > features
> > such as QoS (which tends to be used, if only to separate 
> Internet traffic
> > from VPN traffic).  (My company makes such a system, see my 
> sig for URL.)
> > 
> > > The second was last raised in the Jan 2001 Cook report by 
> Judy Estrin.
> > > Judy's issue relates to having each router having to know the 
> > > best path
> > > through a domain (MPLS) vs. each router knowing the best next 
> > > hop to pass
> > > through a domain (IP).  Whatever feelings people have on this 
> > > issue, it is
> > > still alive in the industry. A summary of the report text can 
> > > be found at:
> > > http://www.cookreport.com/09.10.shtml
> > > Her solution(s) should NOT be expected to reach the 
> > > marketplace soon, but
> > > the points raised are valid for large scale networks.
> > 
> > Thanks for the URL, it was an interesting read, and I look 
> forward to
> > seeing
> > what Packet Design come up with.  However, since it would 
> seem to require
> > new or updated routing protocols and SPF algorithms, this 
> may take some
> > time
> > - although millisecond IGP convergence would be incredibly 
> useful, it may
> > be
> > easier to use layer 2 mechanisms until this becomes available.
> > 
> > The Cook article also seems to equate MPLS with MPLS TE by 
> saying that
> > MPLS
> > is 'string oriented', which is of course not correct, since MPLS is
> > fundamentally connectionless - even those networks that use 
> TE may not use
> > it everywhere, particularly if it is just used to fix major 
> network load
> > imbalances initially.
> > 
> > I guess my main point is that MPLS VPNs are actually 
> connectionless so the
> > scalability problems are mainly to do with routing, not TE 
> LSP setup.
> > 
> > Cheers,
> > 
> > Richard
> > -- 
> > rdonkin@orchestream.com                   http://www.orchestream.com
> > Tel: +44 (0)20 7348 1507 (direct)         Orchestream Ltd.
> >      +44 (0)20 7348 1500 (switchboard)    Avon House, 
> Kensington Village,
> > Fax: +44 (0)20 7348 1501                  Avonmore Road
> > >>>> IP Service Activation >>>>           London W14 8TS, UK
> >  
> > 
> > -------
> > 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
> 

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