Backup nexthop design

Backup nexthops for FRR

The concept of backup paths is used in several domains: IP-FRR, TI-LFA, MPLS-FRR, etc. A backup path operates differently from an ECMP (or UCMP) path, in that the backup path is not used until some change in the preferred or primary path activates it. The exact details of "triggers" and "activation" are likely to be OS- and/or dataplane-dependent. The goal of this initial work is to offer these features:

1. a list of nexthops can have an associated list of backup nexthops. an individual nexthop can refer to a backup nexthop in that list.

2. the nexthop structs

   1. the existing nhg_hash_entry struct is extended to include a backup nexthop list.

   2. the existing nexthop struct is extended to include a backup index into such a list

3. daemons who send routes to zebra via zapi can include a list of backup nexthops, and can include an optional backup index with each primary or active nexthop.

4. zebra's internal processing of nexthops and the nhg_hash_entry struct are extended to support backups. zebra's hash-entry computation includes the backup information if it's present. backup nexthops are resolved and checked for viability (ACTIVE status) just as primary nexthops are.

5. the zebra dataplane framework captures backup information if it's present, and makes that info available for installation if the actual forwarding plane supports backups.

   1. TODO: would the netlink users like to see some support for backups? currently, that's TBD. it might be possible to add second instance of the primary route, using an inferior metric value, and specifying the backup nexthops.

6. the nexthop-group cli command is extended to support backup indexes for nexthops, and to support a reference to a backup group (by name).

7. for testing, sharpd understands the nexthop-group backup changes, and can use them to exercise the zapi and zebra changes.