[j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
Saku Ytti
saku at ytti.fi
Sat Jul 7 17:10:09 EDT 2018
On Sat, 7 Jul 2018 at 22:58, Mark Tinka <mark.tinka at 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
More information about the juniper-nsp
mailing list