[c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs

Fri Aug 29 17:54:59 EDT 2014

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)
waris at cisco.com<mailto:waris at 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 <jwbensley at gmail.com<mailto:jwbensley at gmail.com>>
Date: Friday, August 29, 2014 at 1:03 AM
To: "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>" <cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
Subject: Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs

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