There are a number of solutions like using BGP labeled unicast, downstream on demand labels, or service level solutions like multi segment pseudowires. We have thousands of MPLS CPEs deployed at this point. Those endpoints are all L2 pseudowires, which are end to end or terminate into "virtual" L3 interfaces within VPNs. There is no way to inject anything, I have tested it extensively.
Downsides to using MPLS CPEs is right sizing IGP areas and figuring out how to extend services. EVPN should help out with things as well. Phil From: Saku Ytti Sent: 3/4/2013 12:33 To: [email protected] Subject: Re: [c-nsp] MPLS down to the CPE On (2013-03-04 16:04 +0100), William Jackson wrote: > I wanted to find out how many people run mpls down to the CPE ( owned by SP > but co-located at customer ). > We are looking for pros/cons of doing so. > Security is the main concern, we have heard quite a lot about it as the > current trend, but in reality is it a practise? I don't think it's very common, due to security reasons. Technically RFC4364 OptB would be quite nice replacement for VRFLite. But right now no one is implementing the 'uRPF/strict' style label checking RFC mandates, I know IOSXR short will. Maybe L2 pseudowires end-to-end from CEs securely probably isn't possible today. As labels are not randomized it's actually quite practical to send traffic to arbitrary L3 MPLS VPN, especially if you know what vendor they are running (to know where to start looking). -- ++ytti _______________________________________________ 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/
