BGP based VPLS isn't that much to deploy... It's actually easier then manual VPLS ... It's similar to saying , RR-based ibgp is easier than manually full meshing an ibgp environment ....Like ATM LANE was easier then full meshing SPVC's , lol , God rest your soul ATM
Aaron > On Jul 7, 2018, at 7:38 AM, Mark Tinka <mark.ti...@seacom.mu> wrote: > > > >> On 7/Jul/18 14:16, Saku Ytti wrote: >> >> I feel your frustration, but to me it feels like there is very little >> sharable knowledge in your experience. > > Hmmh, I thought there was a fair bit, explicit and inferred. I feel > Alexandre could have gone on more than his TL;DR post allowed for :-). > > >> You seem to compare full-blown >> VPLS, with virtual switch and MAC learning to single LDD martini. You >> also seem to blame BGP pseudowires for BGP transport flapping, clearly >> you'd have equally bad time if LDP transport flaps, but at least in >> BGP's case you can have redundancy via multiple RR connections, with >> LDP you're reliant on the single session. > > Sounded like BGP flaps was one of several problems Alexandre described, > including an unruly BGP routing table, et al. > > Not sure how relevant RR redundancy is per your argument, as ultimately, > a single customer needing an end-to-end pw is mostly relying on the > uptime of the PE devices at each end of their circuit, and liveliness of > the core. If those pw's are linked by an LDP thread, what would a 2nd > LDP-based pw (if that were sensibly possible) bring to the table? I'm > not dissing BGP-based pw signaling in any way or form, but for that, > you'd need "Router + IGP + BGP + RR + RR" to be fine. With LDP-based > signaling for just this one customer, you only need "Router + IGP + LDP" > to be fine. > > Personally, I've never deployed VPLS, nor had the appetite for it. It > just seemed like a handful on paper the moment it was first published, > not to mention the war stories around it from the brave souls that > deployed it when VPLS was the buzzword then that SDN is these days. It > certainly made the case for EVPN, which I still steer clear from until I > find a requirement that can't be solved any other way. > > Again, no dis to anyone running VPLS; just much respect to you for all > your nerve :-). > > Mark. > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp