IETF Logo Mail Archive

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

Vineet Vashishth <vin.vashishth@gmail.com> Mon, 20 February 2012 18:24 UTC

Return-Path: <vin.vashishth@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7121F85B8 for <dime@ietfa.amsl.com>; Mon, 20 Feb 2012 10:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvZz1Uksu2M4 for <dime@ietfa.amsl.com>; Mon, 20 Feb 2012 10:24:10 -0800 (PST)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD721F85B6 for <dime@ietf.org>; Mon, 20 Feb 2012 10:24:06 -0800 (PST)
Received: by wgbgn7 with SMTP id gn7so3348156wgb.1 for <dime@ietf.org>; Mon, 20 Feb 2012 10:24:06 -0800 (PST)
Received-SPF: pass (google.com: domain of vin.vashishth@gmail.com designates 10.180.93.4 as permitted sender) client-ip=10.180.93.4;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of vin.vashishth@gmail.com designates 10.180.93.4 as permitted sender) smtp.mail=vin.vashishth@gmail.com; dkim=pass header.i=vin.vashishth@gmail.com
Received: from mr.google.com ([10.180.93.4]) by 10.180.93.4 with SMTP id cq4mr19195263wib.21.1329762246210 (num_hops = 1); Mon, 20 Feb 2012 10:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yyRoUzxlju10roA3Rg/JaVSUVjCHrm0YUyZJbOTQzC8=; b=X+7z/3Y8444u9tvFjjSnU/lUr5hByKKCQTS2I2PzrNRprO/gKQBOqttNfvmIuF9ZqD 6E0PpUkGhnVnd1MWuBICdbnu/y7WfGpB2nZ2IFWYi2ULo5QXL6yljrcGOaC4q4FzBLZR 4RtNGjlpRlhZCmHKYIpc+YflYBFTw4j9/a6CI=
MIME-Version: 1.0
Received: by 10.180.93.4 with SMTP id cq4mr15904002wib.21.1329762243761; Mon, 20 Feb 2012 10:24:03 -0800 (PST)
Received: by 10.223.4.198 with HTTP; Mon, 20 Feb 2012 10:24:03 -0800 (PST)
Received: by 10.223.4.198 with HTTP; Mon, 20 Feb 2012 10:24:03 -0800 (PST)
In-Reply-To: <BD10179EF7D5DF49986CE3BD4FFF14E62EC3367A@blr-exch-1.sandvine.com>
References: <BD10179EF7D5DF49986CE3BD4FFF14E62EC3367A@blr-exch-1.sandvine.com>
Date: Mon, 20 Feb 2012 23:54:03 +0530
Message-ID: <CAJz0M+gqJWaj-dO4eOoc--vDY8b2OKyyKPo5qDbWJjEXEOkx0Q@mail.gmail.com>
From: Vineet Vashishth <vin.vashishth@gmail.com>
To: Krishna Prasad <kprasad@sandvine.com>
Content-Type: multipart/alternative; boundary="f46d043c80682cd4f004b96966fe"
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Alternate (secondary) peers in diameter commands
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2012 18:24:14 -0000

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> 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
> https://www.ietf.org/mailman/listinfo/dime
>
>

v2.23.0 | Report a Bug | By Email