Before doing OptB, consider the implications. a) no per customer QoS b) no per customer ACL c) no per customer counters d) need 100% trust on far end, unless RFC4364 page32 last sentence is implemented (it is not)
If you have 100% trust, why not just do straight up OptC or native? If you don't have 100% trust, you need to do OptA. There has been some ideas thrown around how to solve this issue, but not enough traction. What most people doing MPLS NNI's want is OptA like trust, OptB like provisioning, with optional ability to add QoS/ACL/counters when needed. There is no technical reason it couldn't exist. I've spent all 5min thinking about this, and I'd love to see something like this http://ip.fi/mpls-optX.txt On 19 May 2016 at 16:40, Anand Anand <myemail.ana...@gmail.com> wrote: > Hi, > > Looking for Option B l2vpn configuration using Juniper MX. > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
