Re: [Dime] Alternate (secondary) peers in diameter commands

Hi Vineet,
   The secondary/failover peer should always be pre-decided; just selecting a peer supporting same application is not enough and we can't randomly pick a peer and start failover to that peer. The key question here is, do we need to learn the secondary peers thru configuration ( this how it happens today) or via diameter messaging. My opinion is, as diameter already attempts to standardize the failover/failback procedure why not complete this feature by defining the list of secondary peers to be learnt on diameter signaling. If this information is exchanged via diameter messaging, especially runtime/dynamically this will simplify lot of OAM aspects for the operators in real deployments.

Krishna Prasad.

From: Vineet Vashishth [mailto:vin.vashishth@gmail.com]
Sent: Monday, February 20, 2012 11:54 PM
To: Krishna Prasad
Cc: dime@ietf.org
Subject: Re: [Dime] Alternate (secondary) peers in diameter commands

Hi Krishna,

Yes, diameter protocol does not talk about the implementation of failover and failvack.  But I believe its not a good idea to have a pre-decided set of secondary peers, as the peers which are configured might not be up at exact time, when a diameter node wants to do failover. It should be dynamic selection.

Instead a simpler implementation would be, to select a peer from the list of the locally configured peers (that are up) and which supports same application.

Regards,
Vineet
On Feb 20, 2012 6:26 PM, "Krishna Prasad" <kprasad@sandvine.com<mailto:kprasad@sandvine.com>> wrote:
Diameter experts,
          Diameter base protocol addresses some level of redundancy mechanisms by defining failover and failback procedures and Device Watchdog messages etc. For sure, this simplified or standardized the failover procedures across different implementations which we claim one of the benefits of diameter over RADIUS.
Though the diameter base protocol supports facilities for when to trigger failover/failback procedures, retransmissions  etc..but it does not exactly specify to which alternate peer a diameter node should failover in case of primary peer failure. This is because a diameter node does not know who is secondary for a given primary peer and this is completely left to the implementations choice (probably as a configuration or DNS etc...). What I mean here is, we can left it open for the users to configure secondary peers for a given primary peer. So is it not a good idea to support for diameter nodes to exchange the secondary peers identities also during CER/CEA?
For example client sends CER with its list of secondary peers and server responds with its list of secondary peers in CEA. If there is any change in this list of secondary peers the peers can dynamically exchange this information using 'Diameter Capabilities Update' application. (draft-ietf-dime-capablities-update-07).

I am not sure if this option is already discussed in the working group earlier, if not I would like to know the experts opinion  on this. Does it make sense, completely useless , out of diameter scope, too late to incorporate this in base etc...?

Prasad.
Sandvine Networks

_______________________________________________
DiME mailing list
DiME@ietf.org<mailto:DiME@ietf.org>
https://www.ietf.org/mailman/listinfo/dime