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

Mark Tinka mark.tinka at seacom.mu
Sat Jul 7 08:38:04 EDT 2018



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.


More information about the juniper-nsp mailing list