[j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

[Aaron Gould]

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.tinka at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp