James Bensley wrote:
> 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.

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.

cisco-nsp mailing list  cisco-nsp@puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to