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.
If you have a situation where control of the entire l2 domain rests with
a single competent party (e.g. an ixp vpls fabric), there's no problem
with vpls as a technology from the point of view of bridging control,
even if it's a bit stinky in other areas (e.g. lag / ecmp).
cisco-nsp mailing list firstname.lastname@example.org
archive at http://puck.nether.net/pipermail/cisco-nsp/