Multiple tests attempt to program isolated next hops which are not used by a next hop group

[jeremyrandnokia]

Our gribi server implementation is unable to ack an isolated next hop. Once a next hop is used by at least one next hop group, we are able to ack that next hop group and the next hop(s) it references. Next hop groups are the smallest entry that we can program and given that, we have chosen not to ack isolated next hops.

But, there are multiple tests that attempt to program isolated next hops:

• TestCompliance/Implicit_replace_NH_entry_-_RIB_ACK
• TestCompliance/Implicit_replace_NHG_entry_-_RIB_ACK
• TestCompliance/Get_for_installed_NH_-_RIB_ACK
• TestCompliance/Benchmark_Get_for_next-hops
• TestCompliance/Get_for_installed_NH_-_FIB_ACK

If these tests could ensure that each NH is always referenced by at least one NHG before it expects an ack from the server, that would be ideal.

[robshakir]

For the FIB ACK this seems reasonable, but for the RIB ACK this seems like it would be something that we would expect to be ACK'd. Is there a reason for this implementation choice? Do you expect that there is an ACK when a NHG is created (I think this is the expectation)?

[jeremyrandnokia]

We were planning on having RIB ACK and FIB ACK share a single implementation to reduce the amount of testing required. When a client asks for RIB ACKs, we would still withhold our ACK until we can ensure it is programmed in the FIB and once we have that, we would send the expected RIB ACK. So, the only thing that changes with ACK mode is the value of the ACK that we send.

For sure, when in FIB ACK mode, we will accept a modify request for an isolated NH. The operation will not be ACKed until a subsequent NHG is programmed which references the NH and assuming everything is good, we would then ACK the NH and the NHG.

Now, there isn't really much extra complexity for treating NHs differently when in RIB ACK mode on our side so we are fine with this being focused on the FIB ACK tests only.