[c-nsp] Loop Prevention in VPLS

[James Bensley]

On 18 October 2016 at 10:42, Nick Hilliard <nick at foobar.org> wrote:
> James Bensley wrote:
>> Maybe I'm missing something here but I don't see the problem with VPLS
>> itself, it’s about how you deploy it surely?
>
> this is the problem: in the OP's situation, control of the bridge
> protocols for the L2 domain is split up over multiple parties, neither
> of which has control over the other side.  Each component works fine by
> itself, but when mistakes happen at the administrative edges, bridging
> loops occur and service is lost.
>
> Regardless of who caused the problem in the first place, the service
> provider is invariably blamed.  The root cause of the problem generally
> tends to be a lack of understanding on the part of the customer about
> the design implications of what they are attempting to do, and that
> other technologies (e.g. preferably l3vpn or even multiple l2vpn
> xconnects) might be better options.

So that isn't actually a problem with VPLS nor should it be a red mark
against using VPLS as a technology (note that I'm not a VPLS
evangelist, it is flawed). This isn't exclusive to VPLS, sell
customers BGP sessions without any filtering and see what happens.

This scenario is a problem with how the service is designed, and sold,
accepting the various risks inherent in such a poor design, I'd be
kicking back and not letting this into operational acceptance.

Cheers,
James.