On 28 August 2014 20:35, Saku Ytti <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 https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/