Why failover should happen if an primary and secondary peers are not relevant?

Question

I have a discrepancy for a failover indication. In RFC 3588, it has written if a message

Since the CER/CEA messages cannot be proxied, it is still possible that an upstream agent receives a message for which it has no available peers to handle the application that corresponds to the Command-Code. In such instances, the ’E’ bit is set in the answer message (see Section 7.) with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action (e.g., re-routing request to an alternate peer).
In such instances, the ’E’ bit is set in the answer message with the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action (e.g., re-routing request to an alternate peer).

My query starts from here. If 1st peer is not supporting the Application ID then why it should try for alternate peer? Because it would be same peer then why failover should happen?
Eg.: If in Gx interface PCRF and PCEF. PCRF has forwarded the CCR message to HSS instead of PCEF and has got the reply 3002. Then for obvious reason HSS alternate peer would be another HSS. In this case failover should happen ? Can anybody tell me in this scenario what is right to do ?

Answer 1

The example you have given is a configuration error, so alternate peer also can't process the request. However think of the 'normal' case when request can't be delivered to the primary server due to either network problems or server side issues. In such cases, alternate peer should be able to take over. Generally you can expect the backup server to be at a geographically different location. This is a mechanism to ensure high reliability of the service.

The kind of errors you mentioned will be caught during deployment.