On Sat, 7 Jul 2018 at 22:58, Mark Tinka <mark.ti...@seacom.mu> wrote:
Hey Mark, > I just let iBGP sessions form normally over IGP-mapped paths. Or am I missing > something. Alexandre's point, to which I agree, is that when you run them over LSP, you get all the convergency benefits of TE. But I can understand why someone specifically would not want to run iBGP on LSP, particularly if they already do not run all traffic in LSPs, so it is indeed option for operator. Main point was, it's not an argument for using LDP signalled pseudowires. > Hmmh - not sure I understand your use-case, Saku. > > LDP forms sessions over the IGP. Whatever path is available via IGP is what > LDP will follow, which covers the signaling redundancy concern. If there is some transport problems, as there were in Alexandre's case, then you may have lossy transport, which normally does not mean rerouting, so you drop 3 hellos and get LDP down and pseudowire down, in iBGP case not only would you be running iBGP on both of the physical links, but you'd also need to get 6 hellos down, which is roughly 6 orders of magnitude less likely. The whole point being using argument 'we had transport problem causing BGP to flap' cannot be used as rationale reason to justify LDP pseudowires. > What I would like to hear, though, is how you would overcome the problems > that Alexandre faced with how he, specifically, deployed BGP-signaled VPLS. I would need to look at the details. > How differently would you do it? I would provision both p2mp and p2p through minimal difference, as to reduce complexity in provisioning. I would make p2p special case of p2mp, so that when there are exactly two attachment circuits, there will be no mac learning. However if you do not do p2mp, you may have some stronger arguments for LDP pseudowires, more so, if you have some pure LDP edges, with no BGP. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp