Well Hierarchical MPLS now with a fancy name Unified MPLS has been around since the advent of RFC 3107 and is how any big scale inter-as MPLS opt10C should have been deployed. I believe now with BGP PIC and IP FRR Cisco added a very appealing factor to it for people who do not necessarily depend on RFC3107 but would like to start using it for "MPLS all the way down to access layer" approach as it indeed allows your core(s) to scale endlessly.
adam -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Pshem Kowalczyk Sent: Saturday, July 06, 2013 11:19 PM To: Phil Bedard Cc: [email protected] Subject: Re: [c-nsp] MPLS down to the CPE There are ways of separating the 'core' MPLS from 'access' MPLS, with separate IGP domains. Cisco came up (well not really, but at least they made their devices compliant) with Unified MPLS (http://www.cisco.com/en/US/prod/collateral/optical/ps5726/ps11348/white_pap er_c11-656286_ps6557_Products_White_Paper.html). This sort of setup scales very well for mobile backhaul, but also can be used for MetroE (L2) backhaul. For us the biggest advantage comes from the fact that existing MPLS network can be easily extended into access, with minimal changes to the core (i.e. once UMPLS is set up in the core - services are only provisioned onto the CPE). We're considering this setup also for L3 services - it reduces the number of touch points to get the service running. Instead of provisioning the CE and then two PEs - only one (CPE-PE) has to be provisioned. kind regards Pshem On 7 July 2013 03:16, Phil Bedard <[email protected]> wrote: > Most of the time these aren't L3 customers it is L2VPN. Like an > instance doing cell backhaul where a customer wants two circuits which > take diverse paths around a ring. You can do it with G.8032 and > different VLANs but its somewhat easier using MPLS along with the > benefit of the 50ms protection RSVP-TE can provide. Or IP FRR If you > aren't in a ring scenario which breaks it. > > Phil From: Andrew Miehs > Sent: 7/6/2013 5:07 > To: [email protected] > Cc: [email protected] > Subject: Re: [c-nsp] MPLS down to the CPE On Sat, Jul 6, 2013 at 6:16 > AM, Mark Tinka <[email protected]> wrote: > >> On Tuesday, March 05, 2013 03:23:43 PM Saku Ytti wrote: >> >> > Not at all. But adding MPLS to customer would increase our >> > exposure. >> >> At $previous_job, this was a serious consideration, mostly because >> the customers were starting to pressure ISP's into making redundancy >> not only native, but usable without much input from the customer. >> > > Don't see why adding MPLS would help very much here - especially > considering the security risk! > > What is the difference on input for the customer between connecting to > a PE, or connecting to a CE provided by yourselves? > The main reason for running a PE out to a customer site would be if > the customer requires a lot of different VPNs/ VRFs which you are > routing for him - L3 tunnels vs L2 - and you don't have a leased line > capable of separating these VPNs... > > So why couldn't you just run a pair of 3900s CEs (eBGP private ASes > between PEs and CEs, iBGP between the two CEs) and HSRP/ GLBP for the > customer side failover? > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
