[c-nsp] Loop Prevention in VPLS

[Mark Tinka]

On 18/Oct/16 14:00, Nick Hilliard wrote:

>
> not quite that simple either.  Plenty of enterprise network admins feel
> confident enough about their L2 design skills that they are quite happy
> to shout down service providers salescritters and SEs with "sell us this
> or we'll take our business to someone else who'll do it for us", without
> realising the extent to which their previous network stability totally
> depended on sensible STP defaults on their switching gear that they
> weren't even aware of.  They also don't understand why bridging L2
> across cities, countries or in some cases, continents is rarely a good idea.
>
> Previously, I used to take the approach of: "ok, but please acknowledge
> the following email where we're going point out scenarios A, B, C and D,
> where we believe your network design is going to fall over sooner or
> later, causing catastrophic service loss".  These days, I've given up
> with that (for a wide variety of reasons) and actively work to remove
> vpls from product portfolios, the reason being that even if you point
> these things out to customers in advance, the politics of service loss
> management often take a disproportionate amount of time to handle.  In
> the case of vpls in particular, this alone has a serious impact on
> product profitability.
>
> It's not really the same as selling unfiltered bgp sessions: bgp is
> designed to provide policy control, so the service provider can protect
> both themselves and their customer against customer stupidity.  L2
> evolved without any policy control, so regardless of intent, it is a bad
> idea to bridge p2mp domains together from different administrative
> domains without strict controls in place - the sorts of controls that
> wouldn't generally work for an arbitrary enterprise wanting a flat
> multi-point network between multiple sites.
>
> Obviously, ymmv, but this is my experience.

+1.

Mark.