[j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
mark.tinka at seacom.mu
Sun Jul 8 04:19:54 EDT 2018
On 7/Jul/18 23:10, Saku Ytti wrote:
> Alexandre's point, to which I agree, is that when you run them over
> LSP, you get all the convergency benefits of TE.
Unless you've got LFA (or BFD, for the poor man), in which case there is
no real incremental benefit.
We run BFD + LFA for IS-IS. We've never seen the need for RSVP-TE for
> 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.
We run all of our IPv4 and l2vpn pw's in (LDP-generated) LSP's. Not sure
if that counts...
I'm not sure whether there is a better reason for BGP- or LDP-signaled
pw's. I think folk just use what makes sense to them. I'm with Alexandre
where I feel, at least in our case, BGP-based signaling for simple p2p
or p2mp pw's would be too fat.
> 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
So LDP will never be more stable than your IGP. Even with
over-configuration of LDP, it's still pretty difficult to totally mess
it up that it's unstable all on it own.
If my IGP loses connectivity, I don't want a false sense of session
uptime either with LDP or BGP. I'd prefer they tear-down immediately, as
that is easier to troubleshoot. What would be awkward is BGP or LDP
being up, but no traffic being passed, as they wait for their Keepalive
Hello's to time out.
> 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
Agreed that EVPN and VPLS better automate the provisioning of p2mp pw's.
However, this is something you can easily script for LDP as well; and
once it's up, it's up.
And with LDP building p2mp pw's, you are just managing LDP session
state. Unlike BGP, you are not needing to also manage routing tables, e.t.c.
More information about the juniper-nsp