[AusNOG] MPLS/VPLS solution

[Andrew Fort]

On Fri, Sep 10, 2010 at 11:48 AM, Ben Dale <bdale at comlinx.com.au> wrote:
> Hi Arman,
>
> On 10/09/2010, at 11:13 AM, Arman Hossain wrote:
>
>> Some discussions about VPLs & MPLS
>>
>> http://blogs.nil.com/blog/2008/06/19/vpls-is-it-hot-or-is-it-not/
>>
>> Regards
>> Arman
>
> I think the article misses the key selling point of VPLS which is separation of routing from customer and provider, in which case there should never be any reason to see broadcast storms inside a VPLS when all CE devices are L3.

If you're trolling, shame on me.... ;)

You've never experienced seen a faulty transceiver?  A misconfigured
customer device?  Never misconfigured an access, agg or core device
yourself?  It's OK, we all make mistakes.

> In general it's a good practice to implementing MAC-limiting on VPLS PE anyway so that only a single MAC is learnt from the customer (being the CE router's WAN-facing interface) which ensures they don't cause grief when they accidentally plug in a switch.

People like VPLS because it is simple and allows them to use
inexpensive equipment.  Some providers only do 1-to-N site VPLSes
(with mesh spoke LSPs, f.e.), some will do any-to-any sites.
Obviously there's a reason some provider's wont do any-to-any.
Customers will buy switches to interconnect their sites because they
are cheaper than routers, and because _you are providing them a single
broadcast domain_, rather than a bunch of links which aren't in the
same domain.  If this weren't the case, why would they buy a VPLS,
then?  (They can route between their sites more effectively using
routing protocols, if they have to buy routers).

If your customers are so well trained they buy VPLSes and then don't
put switches on, all that's happened is more money has been spent for
equipment which does the same stuff in a different way as you used to
do it.   This tends to make everyone unhappy.

> Bridging multiple sites over a WAN is always fraught with danger, but certainly works when design and scaling is well thought out.

It can scale specifically when you disable MAC learning on the
equipment involved (which you can do on a P2P ethernet service).  You
cannot do this on a VPLS, so large VPLS will always have this problem.

Rule of thumb: if your ethernet service provider provides P2MP bridged
services, your service is far more likely to be disrupted by other
customers' problems, or by random, byzantine equipment failure on the
network causing meltdown (despite the use of protective features).  I
cite things like the recent TWE outage, in case you're not convinced.

My own slightly cynical view is that VPLS was mostly a technical
solution to a technical problem - providing multipoint services on
Juniper routers.  It doesn't address the main issues of ethernet LANs
- shared fate of all devices on the broadcast domain if there is even
one very poorly controlled player.

-a