pseudowire nexthop tracking re-think

[mjstapp]

Zebra does some special-purpose work - and maintains some special-purpose state - to track reachability of pseudowires' destinations. That seems a bit awkward: really, ldp should be registering for its pws' destinations, and deciding what to do as zebra notifies ldp about reachability changes in the normal/common way. Zebra shouldn't really have to have the special chunks of code that it currently is carrying. This issue is a tracker for deciding whether to implement a change like that.

[rwestphal]

+1 to this.

The reason the pseudowire nexthop tracking was implemented in zebra is that static pseudowires are also possible, and staticd didn't exist when pseudowires were implemented. So the NHT code was modified to handle pseudowire nexthops separately, in a similar fashion of how static routes nexthops were handled.

Now I think it would make sense to move static pseudowires to staticd and remove those special chunks of code from zebra_rnh.[ch] as you suggested. The only issue is that adapting ldpd to do do nexthop tracking like the other daemons do might be a bit challenging. Pseudowire signaling using LDP is incredibly complex (the whole thing was a bad idea in the first place). I remember spending a month or so working with Bingen to make things work on several different test scenarios. It's something doable, but should require a lot of care to avoid introducing regressions (the LDP-VPLS topotest should be insufficient to catch all possible problems, unfortunately).