[c-nsp] MPLS down to the CPE

[Adam Vitkovsky]

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:cisco-nsp-bounces at puck.nether.net] On Behalf Of
Pshem Kowalczyk
Sent: Saturday, July 06, 2013 11:19 PM
To: Phil Bedard
Cc: cisco-nsp at puck.nether.net
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 <philxor at gmail.com> 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: mark.tinka at seacom.mu
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MPLS down to the CPE On Sat, Jul 6, 2013 at 6:16 
> AM, Mark Tinka <mark.tinka at seacom.mu> 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  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/