The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: MPLS/VPN question
Hi Alexander, > On the other hand MPLS/VPN as L3-peering-technology has a much higher > convergence-time than a direct FR-circuit. Hmmm interesting. I would say that this is never much higher and also can be sometimes even better. The reason why this is not much higher is that there is quite a few networks running IGPs like EIGRP or OSPF where a convergence is equally proportinal to: * the number of routers in a flat area + * configuration for LSA flooding optimization + * CPU power of your routers. In MPLS-VPN the convergence is quite deterministic as in most cases it depends on the following constants: * configuration of min adv interval on the PE-CE EBGP case (if you use IGP on PE-CE you don't have this delay), * confiuguration of the import bgp scanner on PE, * CPU power of the edge PEs and reflectors used (which in most cases are higher then the low end units connected by F/R PVCs) of the customers. The achivable goal for mpls-vpn convergence is to make it equal to IGP convergence time in the flat area of the same size. Adding all elements together it should not exceed 20-40 sec. Why/When it can be better ? When you have a large set of sites connected in a close to full mesh VPN via L2 media and most of those sites use low end routers. Those would convergence wise benefit well from MPLS-VPN offer by any of the provider. R. > Alexander Marhold wrote: > > Hello ! > > My 2 cents on that as this is a kind of question I often see and get. > > 1.) the main task of the PE (Ingress/Egress LSR) is to allow the MPLS/VPN > based forwarding on the control plane and on the data plane. > Regarding QOS the PE as service provider device runs the DIFFSERV model. > Typically outside the PE sits an CE which is the USER-Interface. > 2.) Things like selection into different VPNs. Address Translation,Protocol > Conversion,protocol specific actions and functions.... > are IMHO CE functions and not PE ones. > > So regarding the actual question: if you need different VPNs for the > traffic, than separate it on the CE and have more than one (logical) CE-PE > connection going into different VPNs. > It is also not recommendable for any Service Provider to do > customer-specific things on the PE. > > Generally spoken, does it make sense to convert an existing FR-network to > MPLS/VPN ? > As always, it depends > Despite the wise rule "never change a running system", there maybe some > reasons > COST, COST,..... > Main advantage of MPLS/VPN is an integrated FULL-MESH whereas FR is a > circuit point-to-point technology. So if you have to any-to-any connect 100 > sites, MPLS/VPN gives you distinct advantage in that case. > On the other hand MPLS/VPN as L3-peering-technology has a much higher > convergence-time than a direct FR-circuit. > .... > > with best regards > > Alexander Marhold > Senior Consultant > PRO IN > > -----Original Message----- > From: Saqib Jang [mailto:saqibj@margallacomm.com] > Sent: Tuesday, March 27, 2001 5:50 AM > To: raszuk@cisco.com > Cc: mpls-ops@mplsrc.com > Subject: RE: MPLS/VPN question > > I think my choice of VoIP (due to the QoS issues surrounding it) > as an example may have confused the issue. Assuming a number of sites have > set-up a FR based overlay network to forward a specific type of traffic > such as HTTP, FTP, or streaming traffic (setting aside the QoS implications > for now). Does it make sense for them to look to get rid of the overlay > network and use their existing last mile links thats used for > all their data traffic in conjunction with an MPLS VPN that supports only > (HTTP, ..) the specific type of traffic supported by their > existing FR network. Or will MPLS VPNs not work for such a scenario? > > Saqib > > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Monday, March 26, 2001 3:41 PM > To: saqibj@margallacomm.com > Cc: mpls-ops@mplsrc.com > Subject: Re: MPLS/VPN question > > Saqib, > > I don't think that the approach of application specific VPNs even makes > sense. L2 or L3 VPNs provide you mainly with connectivity (routing > information distribution). > > For application level scheduling guarantees you should be using the > right QoS tools available both in each hop as well on ingress. That way > you can classify very important traffic (VoIP for example) to be taking > the dedicated LLQ resources at each hop. I don't know how building VPNs > (routing information disgtribution) may replace basic qos engineering in > your network. > > Also the existance or not of NMPLS-BGP VPNs is orthogonal to the > possibiliy of using more complex QoS tools like diffserv aware TE which > can be a perfect complement to the VPNs itself, but not a reason for it. > > R. > > > Saqib Jang wrote: > > > > As I understand it, MPLS/BGP VPNs (per RFC2547) enable site-to-site > > VPNs at for all traffic flowing between sites in the VPN. Can MPLS > > VPNs handle the requirement of creation of VPNs among sites for > > specific types of traffic (say e.g. VoIP traffic)? Would this require > > a VoIP swtich (other type of allication-aware switches) to be an MPLS edge > > router or can a "one size fits all" approach work here (i.e. can standard > > MPLS-aware IP routers create application-specific MPLS VPNs). I'm looking > > for technical rationale (i.e. not company/product positioning) here. > > > > TIA, > > Saqib > > > > Saqib Jang > > Margalla Communications, Inc. > > 3301 El Camino Real, Suite 220 > > Atherton, CA 94027 > > Ph: 650 298 8462 > > Fax: 650 851 1613 > > > > ------- > > 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 ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|