[c-nsp] VPLS Autodiscovery Redundant CE

[Nick Hilliard]

Mohammad Khalil wrote:
> Thanks a lot Nick for your comments
> 
> My customer is heavily deploying VPLS with autodiscovery , if I want to
> suggest replacement what will be the best options?

tl;dr: l3vpn.

The longer answer is that you need to step back and look at what's going
on and where it's leading to.

Lots of VPLS probably means a bunch of different sites with a
requirement to have flat inter-site connectivity.  This works fine to a
certain point and then you run into problems;  handling redundancy is
one of the traditional problems that you run into, namely connecting two
different styles of layer 2 domains together which use different
bridging protocols (stp and split horizon).

IOS implemented PE redundancy to do this; other vendors provide other
solutions (e.g. vpls stp edge, etc).  However these solutions are
patches to work around a fundamental problem with the network design,
namely that layer 2 is not a suitable mechanism for handling
large-scale, complicated multisite connectivity, and if you have a
border between two bridging protocols, you need a translation layer.

Maybe you could use static configuration for situations where you need
PE redundancy.  I haven't tried this: it might work, or it might not,
and most likely if it works, it will cause maintainability problems in
future.  However, this sort of solution is network engineering with
chewing gum and sellotape: you will end up with a poorly built product
which will break easily and has a high administrative cost. It's the
same as any engineering problem: you can often use tools for different
thing, but if you don't choose the right tool for the job, you will run
into problems.

You need to get your customer to think about a design change. This will
mean working with the customer to help them to understand the
limitations of what they are trying to do (broadcast / multicast
management, site-to-site redundancy management, site-to-provider
redundancy management, etc).  It might be that using individual
pseudowires would provide a better solution in the short term because
that would allow them/you to avoid the bridging protocol border
incompatibility problem.  Alternatively, an l3vpn configuration will
scale to as large as the customer needs, and is likely to be a far
better solution in the long term, as layer 3 is designed to handle
redundancy.

If I were you, I would try the static + autodiscovery configuration and
see if it works.  If it does, I would request the customer to
acknowledge in writing that they accept that this is not a recommended
design and it is likely to be prone to failure, and that that you will
not accept any liability for any future connectivity failure which can
be traced to this problem, and that they accept that future connectivity
requirements will need network redesign on their part.

If it doesn't work, you'll need to let them know the bad news that
they'll need to start their network design sooner rather than later.

Incidentally, this is partly a customer management problem: your
customer needs to be educated and you can make money from educating
them.  In the process, you'll end up with a happier customer, a cleaner
network and lower work load, i.e. win for all.  If you continue with
just vpls, it will break your heart.

Nick