Two labels QOS will work fine since bottom label EXP is copied to the top label so there should not be any issues with the QOS in this case if you are using ME family. I have put uRPF in the roadmap on ASR920 but I need customer names since it is required for feature request. I would appreciate if you can unicast me the customer names who would be interested in this feature. I still do not understand why do we need large number of BGP sessions on a single small PE router like ME3600X? Why cannot use Tunk interface where vlan can be differentiator and limit the sessions to 200- 300?
Best Regards, [http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg] Waris Sagheer Technical Marketing Manager Service Provider Access Group (SPAG) wa...@cisco.com<mailto:wa...@cisco.com> Phone: +1 408 853 6682 Mobile: +1 408 835 1389 CCIE - 19901 <http://www.cisco.com/> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: James Bensley <jwbens...@gmail.com<mailto:jwbens...@gmail.com>> Date: Friday, August 29, 2014 at 1:03 AM To: "cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>" <cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>> Subject: Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs On 28 August 2014 20:35, Saku Ytti <s...@ytti.fi<mailto:s...@ytti.fi>> wrote: Dare I say it what access/agg layer boxes (such as ME3x00) from Cisco will perform QoS deeper than one MPLS label? ASR9001 certainly. I'm not sure what ME3x00 could in theory do, it does not seem hard for me to think it could classify based on IP packets for MPLS encapped packets. In any case, label stack would be 1. ... If you're thinking of optionB, label stack would be between ASBRs 1 label deep. Yeah I new the ASR9K could fo it but nothing smaller I know of. Yes our ME3x00's are happy to QoS to one label although I was thinking of MPLS down to CPE with AToM L2VPNs so a 2nd label is required; perhaps a method of copying the EXP from the bottom label to the top label so it can become subject to QoS would be useful. Opt D (Cisco "Opt AB") could be a good tool if you don't need QoS and ACLs on all VPNs, only creating the hybrid Opt A peerings, breaking them out from the Opt B link for VPNs that do need QoS/ACL etc but thats no good if all VPNs require QoS (multi-tenant building with shared CPE, tenant in each VRF and each run's VOIP for example). AB is interesting, I wonder if anyone else implements it, and I guess security is same as B, non-existing. Data-plane is labeled, so you would still need label security. Yeah so we're back to square one. Without uRPF support for MPLS in boxes smaller than ASR9K this is a major feature that Cisco are missing in my opinion. By the time my current project completes will will probably hit 10k BGP sessions to CPEs that could probably be circa 3k~ if we had secure MPLS to the CPE. I've had an off-list recommendation for CsC but getting down to the nuts and bolts of it I would simply end up with another label on the stack making customer traffic 3 labels passing through the core instead of 2. Unless they meant something else I didn't realise? CsC will just obscuring the security issue, making it harder to use a customer tail circuit to originate IP packets to something outside of their VPNs into our CsC core, but it doesn't stopping it. Cheers, James. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
